Network security architecture

ABSTRACT

In an aspect, a network supporting client devices includes one or more network nodes implementing network functions. Such network functions enable a client device to apply a security context to communications with the network when the client device is not in a connected mode. The client device obtains a user plane key shared with a user plane network function implemented at a first network node and/or a control plane key shared with a control plane network function implemented at a second network node. The client device protects a data packet with the user plane key or a control packet with the control plane key. The data packet includes first destination information indicating the first network node and the control packet includes second destination information indicating the second network node. The client device transmits the data packet or control packet.

CROSS REFERENCE TO RELATED APPLICATIONS

This is a divisional application of U.S. application Ser. No. 15/160,326entitled “Network Security Architecture” filed on May 20, 2016, whichclaims priority to and the benefit of U.S. Provisional Application Ser.No. 62/191,459 entitled “IoT Security Architecture” filed on Jul. 12,2015, the entire contents of which are incorporated herein by reference.

INTRODUCTION Field of the Disclosure

Aspects of the disclosure relate generally to communication, and morespecifically, but not exclusively, to an Internet of Things (IoT)network architecture.

BACKGROUND

The capabilities of electronic devices to collect, process, and exchangedata are continuing to grow. Moreover, an increasing number of theseelectronic devices are being provided with network connectivity. Suchcapabilities and features are enabling many electronic devices to evolveinto Internet of Things (IoT) devices. As the number of these types ofelectronic devices continues to rapidly increase, networks may not havethe resources to adequately support these electronic devices.

For example, in an IoT environment, a network (e.g., an LTE network) mayneed to support a large number (e.g., billions) of IoT devices (e.g.,client devices that attach to the network in a reduced data transfermode or a low power consumption mode). Since the amount of resourcesallocated by the network for IoT purposes may be limited, the networkmay not be able to maintain all contexts for these types of devices. Thecontext, which is used for user plane data transmissions for a clientdevice, may reduce the amount of signaling to be performed by the clientdevice in order to communicate with the network. In light of thesecircumstances, the network access node typically removes (e.g., deletes)the client device context when the client device enters an idle mode andestablishes a new client device context when the client device enters aconnected mode (also referred to as an active mode). This idle mode toconnected mode transition involves substantial overhead for a clientdevice in terms of signaling messages. Moreover, such idle mode toconnected mode transitions may cause the client device to remain awakefor longer periods of time and, therefore, may increase the powerconsumption of the client device.

SUMMARY

The following presents a simplified summary of some aspects of thedisclosure to provide a basic understanding of such aspects. Thissummary is not an extensive overview of all contemplated features of thedisclosure, and is intended neither to identify key or critical elementsof all aspects of the disclosure nor to delineate the scope of any orall aspects of the disclosure. Its sole purpose is to present variousconcepts of some aspects of the disclosure in a simplified form as aprelude to the more detailed description that is presented later.

In an aspect, a method for a client device in a network is provided. Theclient device may register to the network, obtain at least a user planekey shared with a user plane network function implemented at a firstnetwork node or a control plane key shared with a control plane networkfunction implemented at a second network node, protect a data packetwith the user plane key or a control packet with the control plane key,and transmit the data packet or the control packet. In an aspect, thedata packet includes first destination information indicating that thedata packet is to be processed at the first network node, the firstdestination information enabling a network access node to forward thedata packet to the first network node, and the control packet includessecond destination information indicating that the control packet is tobe processed at the second network node, the second destinationinformation enabling the network access node to forward the controlpacket to the second network node. In an aspect, the client device mayreceive a packet from the network, determine whether the received packetincludes data or control information, and decode the received packetwith the user plane key or the control plane key based on thedetermination. In an aspect, the client device may decode the receivedpacket by decrypting and verifying the received packet with the userplane key or the control plane key. In an aspect, the client device mayverify the received packet by determining a first message authenticationcode by applying a message authentication code generation algorithmbased on the received packet and either the user plane key or thecontrol plane key, and comparing the first message authentication codeto a second message authentication code associated with the receivedpacket. In an aspect, the client device may obtain at least one of auser plane security context indicating network state information for theclient device with respect to a user plane, or a control plane securitycontext indicating network state information for the client device withrespect to a control plane. In an aspect, the client device may obtainthe user plane security context by deriving a first encryption key and afirst integrity key based on the user plane key, and may obtain thecontrol plane security context by deriving a second encryption key and asecond integrity key based on the control plane key. In an aspect, theuser plane security context or the control plane security context doesnot include access stratum security protection. In an aspect, a userplane network function identifier or a control plane network functionidentifier is included in a header of the received packet, and whereinthe client device is registered in a reduced data transfer mode. In anaspect, the data packet is encrypted or integrity protected, or bothencrypted and integrity protected, based on the user plane key, andwherein the control packet is encrypted or integrity protected, or bothencrypted and integrity protected, based on the control plane key. In anaspect, the client device may register to the network by transmitting arequest to attach to the network, and receiving, from the network, amessage associated with an authentication procedure in response to therequest. In such aspect, the user plane key or the control plane key isobtained based on the message, and the attach request indicates that theclient device is to attach in a reduced data transfer mode.

In an aspect, a client device is provided. The client device may includemeans for registering to the network, means for obtaining at least auser plane key shared with a user plane network function implemented ata first network node or a control plane key shared with a control planenetwork function implemented at a second network node, means forprotecting a data packet with the user plane key or a control packetwith the control plane key, and means for transmitting the data packetor the control packet. The data packet may include first destinationinformation indicating that the data packet is to be processed at thefirst network node, the first destination information enabling a networkaccess node to forward the data packet to the first network node, andthe control packet may include second destination information indicatingthat the control packet is to be processed at the second network node,the second destination information enabling the network access node toforward the control packet to the second network node. In an aspect, theclient device may include means for receiving a packet from the network,means for determining whether the received packet includes data orcontrol information, and means for decoding the received packet with theuser plane key or the control plane key based on the determination. Inan aspect, the means for decoding the received packet is configured todecrypt and verify the received packet with the user plane key or thecontrol plane key. In an aspect, the means for verifying the receivedpacket may be configured to determine a first message authenticationcode by applying a message authentication code generation algorithmbased on the received packet and either the user plane key or thecontrol plane key, and compare the first message authentication code toa second message authentication code associated with the receivedpacket. In an aspect, the client device may further include means forobtaining at least one of a user plane security context indicatingnetwork state information for the client device with respect to a userplane, or a control plane security context indicating network stateinformation for the client device with respect to a control plane. In anaspect, the means for obtaining the user plane security may beconfigured to derive a first encryption key and a first integrity keybased on the user plane key, and wherein obtaining the control planesecurity context comprises deriving a second encryption key and a secondintegrity key based on the control plane key. In an aspect, the userplane security context or the control plane security context does notinclude access stratum security protection. In an aspect, a user planenetwork function identifier or a control plane network functionidentifier is included in a header of the received packet, and whereinthe client device is registered in a reduced data transfer mode. In anaspect, the data packet is encrypted or integrity protected, or bothencrypted and integrity protected, based on the user plane key, andwherein the control packet is encrypted or integrity protected, or bothencrypted and integrity protected, based on the control plane key. In anaspect, the means for registering to the network may be configured totransmit a request to attach to the network, and receive, from thenetwork, a message associated with an authentication procedure inresponse to the request. In such aspect, the user plane key or thecontrol plane key is obtained based on the message, and wherein theattach request indicates that the client device is to attach in areduced data transfer mode.

In an aspect, a method for a network access node is provided. Thenetwork access node may receive a first packet from a client device,determine a next hop network node based on a network attach mode of theclient device, and forward the first packet to the next hop network nodewithout verifying the first packet received from the client device whenthe network attach mode is a reduced data transfer mode. In an aspect,the network access node may receive a second packet from a network node,and forward the second packet received from the network node to theclient device without protecting the second packet when the networkattach mode of the client device is the reduced data transfer mode. Inan aspect, the network access node may receive, from the client device,a request to attach to a network with an indication of the networkattach mode, wherein the network attach mode is the reduced datatransfer mode. In an aspect, the determination of the next hop networknode is based on preconfigured information at the network access node orbased on destination information included in the first packet, whereinthe network attach mode is the reduced data transfer mode. In an aspect,the destination information includes a network function identifier thatenables identification of a network node implementing a networkfunction. In an aspect, the network function identifier is associatedwith a control plane network function implemented at a first networknode or a user plane network function implemented at a second networknode. In an aspect, the network access node may add, to the firstpacket, a temporary identifier associated with the client device,wherein the first packet is a data packet or a control packet, and maystore the temporary identifier. In an aspect, the temporary identifieris a cell radio network temporary identifier (C-RNTI), and wherein thetemporary identifier is stored for a predetermined period of time. In anaspect, the network access node may identify the client device from atemporary identifier in the second packet, wherein the second packet isa data packet or a control packet. In an aspect, the network access nodemay remove the temporary identifier from the second packet prior toforwarding the second packet.

In an aspect, a network access node is provided. The network access nodemay include means for receiving a first packet from a client device,means for determining a next hop network node based on a network attachmode of the client device, and means for forwarding the first packet tothe next hop network node without verifying the first packet receivedfrom the client device when the network attach mode is a reduced datatransfer mode. In an aspect, the network access node may further includemeans for receiving a second packet from a network node, and means forforwarding the second packet received from the network node to theclient device without protecting the second packet when the networkattach mode of the client device is the reduced data transfer mode. Inan aspect, the network access node may further include means forreceiving, from the client device, a request to attach to a network withan indication of the network attach mode, wherein the network attachmode is the reduced data transfer mode. In an aspect, the determinationof the next hop network node is based on preconfigured information atthe network access node or based on destination information included inthe first packet, wherein the network attach mode is the reduced datatransfer mode. In an aspect, the destination information includes anetwork function identifier that enables identification of a networknode implementing a network function. In an aspect, the network functionidentifier is associated with a control plane network functionimplemented at a first network node or a user plane network functionimplemented at a second network node. In an aspect, the network accessnode may include means for adding, to the first packet, a temporaryidentifier associated with the client device, wherein the first packetis a data packet or a control packet, and means for storing thetemporary identifier. In an aspect, the temporary identifier is a cellradio network temporary identifier (C-RNTI), and wherein the temporaryidentifier is stored for a predetermined period of time. In an aspect,the network access node may further include means for identifying theclient device from a temporary identifier in the second packet, whereinthe second packet is a data packet or a control packet. In an aspect,the network access node may further include means for removing thetemporary identifier from the second packet prior to forwarding thesecond packet.

In an aspect, a method for a first network node is provided. The firstnetwork node may establish, at a control plane network functionimplemented at the first network node, a security context for a clientdevice, obtain, at the control plane network function implemented at thefirst network node, a user plane key for a user plane network functionimplemented at a second network node, and transfer, from the controlplane network function implemented at the first network node, the userplane key to the user plane network function implemented at the secondnetwork node. In an aspect, the first network node may establish thesecurity context for the client device by performing a mutualauthentication procedure with the client device. In an aspect, the firstnetwork node may obtain the user plane key by deriving the user planekey from a session credential established during the mutualauthentication procedure. In an aspect, the first network node mayobtain, at the control plane network function implemented at the firstnetwork node, a control plane key for the control plane networkfunction.

In an aspect, a first network node is provided. The first network nodemay include means for establishing, at a control plane network functionimplemented at the first network node, a security context for a clientdevice, means for obtaining, at the control plane network functionimplemented at the first network node, a user plane key for a user planenetwork function implemented at a second network node, and means fortransferring, from the control plane network function implemented at thefirst network node, the user plane key to the user plane networkfunction implemented at the second network node. In an aspect, the meansfor establishing the security context for the client device may beconfigured to perform a mutual authentication procedure with the clientdevice. In an aspect, the means for obtaining the user plane key may beconfigured to derive the user plane key from a session credentialestablished during the mutual authentication procedure. In an aspect,the first network node may further include means for obtaining, at thecontrol plane network function implemented at the first network node, acontrol plane key for the control plane network function.

In an aspect, a method for a network node is provided. The network nodemay obtain, at a user plane network function implemented at the networknode, a security context for a client device. The network node maydetermine, at the user plane network function implemented at the networknode, a key to be used at least for decryption or verification of a datapacket from the client device, receive, at the user plane networkfunction implemented at the network node, the data packet from theclient device, and decrypt and verify, at the user plane networkfunction implemented at the network node, the data packet from theclient device based on the key. In an aspect, network node may obtainthe security context by receiving the security context from a controlplane network function of the network node. In an aspect, the networknode may receive, at the user plane network function implemented at thenetwork node, a data packet for the client device from an applicationserver or gateway. The network node may determine, at the user planenetwork function implemented at the network node, at least one keyassociated with the client device, and may protect, at the user planenetwork function implemented at the network node, the data packet forthe client device using the at least one key. In an aspect, the networknode may transmit, from the user plane network function implemented atthe network node, the data packet for the client device to the next hopnetwork node. In an aspect, the network node may protect the data packetfor the client device by encrypting or integrity protecting the datapacket, or both encrypting and integrity protecting the data packet, forthe client device.

In an aspect, a network node is provided. The network node may includemeans for obtaining, at a user plane network function implemented at thenetwork node, a security context for a client device, means fordetermining, at the user plane network function implemented at thenetwork node, a key to be used at least for decryption or verificationof a data packet from the client device, means for receiving, at theuser plane network function implemented at the network node, the datapacket from the client device, and means for decrypting and verifying,at the user plane network function implemented at the network node, thedata packet from the client device based on the key. In an aspect, themeans for obtaining the security context may be configured to receivethe security context from a control plane network function of thenetwork node. In an aspect, network node may further include means forreceiving, at the user plane network function implemented at the networknode, a data packet for the client device from an application server orgateway, means for determining, at the user plane network functionimplemented at the network node, at least one key associated with theclient device, and means for protecting, at the user plane networkfunction implemented at the network node, the data packet for the clientdevice using the at least one key. In an aspect, the network node mayfurther include means for transmitting, from the user plane networkfunction implemented at the network node, the data packet for the clientdevice to the next hop network node. In an aspect, the means forprotecting the data packet for the client device may be configured toencrypt or integrity protect the data packet, or both encrypt andintegrity protect the data packet, for the client device.

These and other aspects of the disclosure will become more fullyunderstood upon a review of the detailed description, which follows.Other aspects, features, and implementations of the disclosure willbecome apparent to those of ordinary skill in the art, upon reviewingthe following description of specific implementations of the disclosurein conjunction with the accompanying figures. While features of thedisclosure may be discussed relative to certain implementations andfigures below, all implementations of the disclosure can include one ormore of the advantageous features discussed herein. In other words,while one or more implementations may be discussed as having certainadvantageous features, one or more of such features may also be used inaccordance with the various implementations of the disclosure discussedherein. In similar fashion, while certain implementations may bediscussed below as device, system, or method implementations it shouldbe understood that such implementations can be implemented in variousdevices, systems, and methods.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is a block diagram of an Internet of Things (IoT) networkarchitecture in accordance with various aspects of the presentdisclosure.

FIG. 2 is a diagram illustrating a key hierarchy for an IoT networkarchitecture in accordance with various aspects of the presentdisclosure.

FIG. 3 is a diagram illustrating a key hierarchy for encrypting contextsin an IoT network architecture in accordance with various aspects of thepresent disclosure.

FIG. 4 is a diagram illustrating example network states of a clientdevice maintained at various entities in a network.

FIG. 5 is a block diagram illustrating an initial attach procedure by aclient device in an IoT network architecture in accordance with variousaspects of the present disclosure.

FIG. 6 is a signal flow diagram of an exemplary attach procedure by aclient device in an IoT network architecture in accordance with variousaspects of the present disclosure.

FIG. 7 is a block diagram illustrating a data transmission initiated bya client device in an IoT network architecture in accordance withvarious aspects of the present disclosure.

FIG. 8 is a signal flow diagram illustrating an exemplary datatransmission initiated by a client device in an IoT network architecturein accordance with various aspects of the present disclosure.

FIG. 9 is a signal flow diagram of an exemplary client device terminateddata transmission in an IoT network architecture in accordance withvarious aspects of the present disclosure.

FIG. 10 is a diagram illustrating a control plane protocol stack for IoTdata transmission in accordance with various aspects of the presentdisclosure.

FIG. 11 is a diagram illustrating a user plane protocol stack for IoTdata transmission in accordance with various aspects of the presentdisclosure.

FIG. 12 is a diagram of a packet format for transmissions in an IoTnetwork architecture in accordance with various aspects of the presentdisclosure.

FIG. 13 is a diagram of a packet format for transmissions in an IoTnetwork architecture in accordance with various aspects of the presentdisclosure.

FIG. 14 is a signal flow diagram of a tracking area update (TAU)procedure in an IoT network architecture in accordance with variousaspects of the present disclosure.

FIG. 15 is an illustration of an apparatus configured to communicate inan IoT network architecture according to one or more aspects of thepresent disclosure.

FIG. 16 is a flowchart illustrating a method for an apparatus forcommunicating in an IoT network architecture in accordance with variousaspects of the present disclosure.

FIG. 17 is an illustration of an apparatus configured to communicate inan IoT network architecture according to one or more aspects of thepresent disclosure.

FIG. 18 (including FIGS. 18A and 18B) is a flowchart illustrating amethod for an apparatus for communicating in an IoT network architecturein accordance with various aspects of the present disclosure.

FIG. 19 is an illustration of an apparatus configured to communicate inan IoT network architecture according to one or more aspects of thedisclosure.

FIG. 20 is a flowchart illustrating a method for an apparatus forcommunicating in an IoT network architecture in accordance with variousaspects of the disclosure.

FIG. 21 is a flowchart illustrating a method for an apparatus forcommunicating in an IoT network architecture in accordance with variousaspects of the disclosure.

FIG. 22 is a flowchart illustrating a method for an apparatus forcommunicating in an IoT network architecture in accordance with variousaspects of the disclosure.

DETAILED DESCRIPTION

The detailed description set forth below in connection with the appendeddrawings is intended as a description of various configurations and isnot intended to represent the only configurations in which the conceptsdescribed herein may be practiced. The detailed description includesspecific details for the purpose of providing a thorough understandingof various concepts. However, it will be apparent to those skilled inthe art that these concepts may be practiced without these specificdetails. In some instances, well known structures and components areshown in block diagram form in order to avoid obscuring such concepts.

In a network, such as Long Term Evolution (LTE) network, the user planesecurity terminates at the network access node (e.g., eNodeB, basestation, or network access point). As such, the network access nodeshould have a context for a client device (also referred to as anInternet of Things (IoT) device) for user plane data transmissions. Forexample, the client device may be a cellular telephone (e.g., asmartphone), a personal computer (e.g., a laptop computer), a gamingdevice, or any other suitable device that is configured to communicatewith the network. The context for the client device may include networkstate information associated with the client device, such as a clientdevice security context, and/or an evolved Universal MobileTelecommunications System (UMTS) Terrestrial Radio Access Network(E-UTRAN) radio access bearer (eRAB) (e.g., radio bearer and S1 bearer).The context for the client device may reduce the amount of signaling tobe performed by the client device in order to communicate with thenetwork.

As discussed above, a network (e.g., an LTE network) may need to supporta large number (e.g., billions) of Internet of Things (IoT) devices. Forexample, an IoT device may be a client device that attaches to thenetwork as an IoT device (e.g., the client device may operate in an IoTdevice mode), attaches in a low power consumption mode, or attaches forpurposes of reduced data transfer between the client device and thenetwork. In an aspect, the reduced data transfer mode may involveinfrequent small data (e.g., a single packet or a few packets)transmissions or short bursts of data. Therefore, in the presentdisclosure, the term client device used herein also refers to an IoTdevice. A client device, for example, may be a cellular telephone (e.g.,a smartphone), a personal computer (e.g., a laptop), a gaming device, anautomobile, an appliance, or any other suitable device that isconfigured to communicate with the network. In some aspects, the clientdevice may be referred to as a user equipment (UE) or an access terminal(AT). In some aspects, a client device as referred to herein may be amobile device or a static device.

Since the amount of resources, such as IoT network functions and otherIoT related equipment, allocated by the network for IoT purposes may belimited, the network functions may not be able to maintain the contextsfor all client devices. Moreover, IoT device may frequently be inactive.For example, client devices may wake up every 10 minutes or longer, sendtraffic to a server, and immediately enter a sleep mode.

In light of these circumstances, the network access node typicallyremoves (e.g., deletes) the client device context when the client deviceenters an idle mode and establishes a new client device context when theclient device enters a connected mode (also referred to as an activemode). This idle mode to connected mode transition involves substantialoverhead for a client device in terms of signaling messages. Moreover,such idle mode to connected mode transitions may cause the client deviceto remain awake for longer periods of time and, therefore, may increasethe power consumption of the client device.

The aspects disclosed herein include network architectures for clientdevices, from an upper-layer perspective, for achieving ultra-low clientdevice power consumption, a large number of devices per cell, and/or asmall spectrum. Dedicated network functions are introduced to enableindependent deployment and remove scalability/inter-workingrequirements. Security is anchored at an IoT network function (alsoreferred to as an IoT Function (IoTF)) implemented at a network device.The IoT network function may allow the architecture to achieve efficientdata transmission for client devices. According to various aspects, thearchitecture may allow no security context to be maintained at a networkaccess node (e.g., eNB, base station, network access point) for datatransfer to or from client devices.

To avoid affecting normal packet data network (PDN) connection/trafficof client devices, dedicated core network resources are allocated forsmall data transfer. The network may allocate dedicated physical (PHY)layer resources for access control to also limit small data traffic. Aclient device context may be used for small data transfer to eliminate aclient device's semi-persistent context at an IoTF when the clientdevice is in an idle state.

In an aspect, the IoTF may include a control plane IoTF (IoTF-C) and auser plane IoTF (IoTF-U). In some aspects, such IoTF-C and IoTF-U may beimplemented in a single IoTF. In other aspects, such IoTF-C and IoTF-Umay be implemented as separate IoTFs. In an aspect of the presentdisclosure, an IoTF-C may have functions similar to a mobilitymanagement entity (MME). In an aspect of the present disclosure, anIoTF-U may be the mobility and security anchor for user plane datatraffic. In an aspect of the present disclosure, an IoTF-U may havefunctions similar to a serving gateway (S-GW) and/or a network accessnode (e.g., evolved Node B (eNB), base station, or network accesspoint).

In order to allow the network functions (e.g., IoTF-C, IoTF-U) tooptimize resource usage for client devices, various aspects of thedisclosed IoT network architectures may implement a design protocol inwhich a context for a client device is carried in a packet (e.g., IPpacket) and the IoTF (e.g., an IoTF that includes an IoTF-C and anIoTF-U) creates the context for the client device opportunistically.This enables network functions to maintain minimal to no network stateinformation for the client device and minimal to no signaling overhead.It should be understood that the disclosed IoT network architectures andthe functions included therein may be used for any type of small datatransfer. For example, a client device (e.g., smartphone) may have anominal mode where it establishes a connection and transfers data, butalso uses procedures as disclosed herein to transfer data using a clientdevice context.

IoT Network Architecture

FIG. 1 is a block diagram of an IoT network architecture 100 inaccordance with various aspects of the present disclosure. As shown inFIG. 1, the IoT network architecture 100 includes a client device 102(also referred to as an IoT device), a network access node 104, anetwork device 105, a service network 110, and a home subscriber server(HSS)/authentication, authorization, and accounting (AAA) server 112. Inone aspect, the network access node 104 may be an eNB, base station, ora network access point. In one aspect, the network device 105 mayinclude one or more processing circuits and/or other appropriatehardware configured to implement an IoTF. In one aspect of the presentdisclosure, an IoTF may include a control plane IoT Function (IoTF-C)106 and a user plane IoT Function (IoTF-U) 108. For example, the IoTF-C106 may be implemented at a first network node 107 and the IoTF-U 108may be implemented at a second network node 109. In accordance with thevarious aspects disclosed herein, the term “node” may represent aphysical entity, such as a processing circuit, a device, a server, or anetwork entity, included in the network device 105. Accordingly, forexample, a network node may be referred to as a network node device.

In one aspect, the IoTF-C 106 and the IoTF-U 108 may be implemented atthe same hardware platform (e.g., one or more processing circuits andother associated hardware components, such as memory). In such aspect,for example, the IoTF-C 106 may be implemented at a first virtualmachine (e.g., a first operating system) provided on a hardware platform(e.g., the network device 105) and the IoTF-U 108 may be implemented ata second virtual machine (e.g., a second operating system) provided onthe hardware platform.

As shown in FIG. 1, the IoTF-C 106 is in communication with the networkaccess node 104 via a first S1 connection 116, and the IoTF-U 108 is incommunication with the network access node 104 via a second S1connection 114. In an aspect of the present disclosure, the servicenetwork 110 may include a number of entities, functions, gateways,and/or servers configured to provide various types of services. Forexample, the service network 110 may include a short message entity(SME) 118, a machine type communication interworking function (MTC-IWF)120, an IoT server 122, and/or a packet data network (PDN) gateway(P-GW) 124. It should be understood that the service network 110disclosed in FIG. 1 serves as one example and that in other aspects, theservice network 110 may include different types of entities, functions,and/or servers than those disclosed in FIG. 1.

In an aspect of the present disclosure, the IoTF implemented at thenetwork device 105 may provide control plane and user planefunctionality. In an aspect of the present disclosure, the IoTF-C 106handles control plane signaling (e.g., packets carrying controlinformation, herein referred to as “control packets”) for clientdevices. For example, the IoTF-C 106 may perform mobility and sessionmanagement for client devices, perform authentication and key agreement(also referred to as an AKA procedure) with client devices, and/or maycreate security contexts for client devices. In an aspect of the presentdisclosure, the IoTF-C 106 may derive control plane (CP) key(s) 126 forcontrol plane traffic associated with the client device 102, user plane(UP) key(s) 128 for user plane traffic associated with the client device102, and/or a context key(s) 130 for generating an encrypted clientdevice context and/or encrypted network reachability context for theclient device 102. In an aspect of the present disclosure, the IoTF-C106 may provide the user plane key(s) 128 and/or at least one of thecontext key(s) 130 to the IoTF-U 108. Accordingly, in some aspects, theIoTF-U 108 may include the user plane key(s) 128 and/or the contextkey(s) 131 provided by the IoTF-C 106.

In an aspect of the present disclosure, the IoTF-U 108 may handle userplane traffic for client devices. For example, the IoTF-U 108 may derivea ciphering key and an integrity key (e.g., an Authenticated Encryptionwith Associated Data (AEAD) cipher using the UP key 128), create aclient device context (also referred to as an IoT device context)on-the-fly, authenticate and decipher uplink (UL) packets sent by clientdevices and forward the uplink packets to a PDN or P-GW (e.g., P-GW124), cipher and authenticate downlink (DL) packets for connected clientdevices and forward the downlink packets to the next hop network accessnode (e.g., eNB), and/or buffer downlink packets for idle client devicesduring paging. In an aspect of the present disclosure, the IoTF-U 108may serve as a mobility and security anchor for data traffic.

Exemplary Key Hierarchy for an IoT Network

FIG. 2 is a diagram illustrating a key hierarchy 200 for an IoT networkarchitecture (e.g., IoT network architecture 100) in accordance withvarious aspects of the present disclosure. In FIG. 2, the key K_(IoT)202 may be a secret key stored permanently in a Universal MobileTelecommunications System (UMTS) Subscriber Identity Module (USIM) of aclient device (e.g., the client device 102) and an Authentication Center(AuC)) of the network. The integrity key (IK) and cipher key (CK) (shownas IK, CK 204 in FIG. 2) are a pair of keys derived in the AuC and USIMduring an AKA procedure. With reference to FIG. 1, during the AKAprocedure, the IoTF-C 106 may receive authentication vectors (AVs) fromthe HSS/AAA server 112 which contain a key (shown in FIG. 2 as the keyK_(ASME) 206) from an Access Security Management Entity (ASME). TheIoTF-C 106 may derive a control plane key (K_(CP)) 208 and a user planekey (K_(UP)) 214 from the key K_(ASME) 206. The IoTF-C 106 may providethe key K_(UP) 214 to the IoTF-U 108. The IoTF-C 106 may derive anencryption key K_(IoT-CPenc) 210 and an integrity protection keyK_(IoT-CPint) 212 from the key K_(CP) 208. The IoTF-U 108 may derive anencryption key K_(IoT-UPenc) 216 and an integrity protection keyK_(IoT-UPint) 218 from the key K_(UP) 214.

FIG. 3 is a diagram illustrating a key hierarchy 300 for encryptingcontexts in an IoT network architecture (e.g., IoT network architecture100) in accordance with various aspects of the present disclosure. In anaspect of the present disclosure, with reference to FIG. 1, the IoTF-C106 may randomly generate a control plane client device contextencryption key (K_(CDC-IoTF-C)) 304 and a user plane client devicecontext encryption key (K_(CDC-IoTF-U)) 306 for a client device (e.g.,client device 102) based on a context key K_(CDC-IoTF) 302 for a clientdevice. In an aspect of the present disclosure, with reference to FIG.1, the IoTF-C 106 may randomly generate a network reachability context(NRC) encryption key (K_(NRC-IoTF-C)) 310 for the control plane based ona context key K_(NRC-IoTF) 308. The IoTF-C 106 may further randomlygenerate a network reachability context (NRC) encryption key(K_(NRC-IoTF-U)) 312 for the user plane based on the context keyK_(NRC-IoTF) 308. In one aspect, the key K_(NRC-IoTF-C) 310 and the keyK_(NRC-IoTF-U) 312 may be generated for an application service or a P-GW(e.g., P-GW 124).

Exemplary Network States of a Client Device

In a wireless communication system (e.g. an LTE network), network statesare defined for a client device for mobility management (e.g., EvolvedPacket System Mobility Management (EMM)). Such network states enableefficient communication between a client device and other entities inthe network. In an aspect of the present disclosure, a client device(e.g., client device 102 in FIG. 1) may be in a deregistered state or aregistered state.

For example, when the client device is in a deregistered state, thecontext for the client device may be stored in the HSS. The networkholds no valid location or routing information for the client device,and the client device is not reachable.

As another example, the client device may enter a registered state by asuccessful registration with the network. In an aspect of the presentdisclosure, the client device may perform such registration byperforming an attach procedure with the network. In the registeredstate, the client device has at least one active PDN connection. Theclient device also has an Evolved Packet System (EPS) security contextset up. It should be noted that the deregistered and registered statesassume that the client device has credentials (e.g., there is asubscription available in the HSS) for the network.

A wireless communication network (e.g., an LTE network) may furtherinclude network states defined for a client device for Evolved PacketSystem Connection Management (ECM). Accordingly, a client device (e.g.,client device 102 in FIG. 1) in a registered state may be in one of twostates (also referred to as sub-states of the registered state), such asan idle state or a connected state. In the idle state, noNon-Access-Stratum (NAS) signaling connection exists between the clientdevice and the other network entities. In addition, the client devicemay perform cell selection/reselection and public land mobile network(PLMN) selection. There may be no context for the client device in theradio access network (e.g., network access node). Moreover, there may beno S1-MME and no S1-U connection for the client device in the idlestate.

In the connected state, the location of the client device is known inthe MME with an accuracy of a serving access network identifier (e.g.,eNB identifier (ID), base station ID, or network access point ID).Mobility of the client device is handled by a handover procedure.Moreover, a signaling connection exists between the client device andthe MME. The signaling connection may be made up of two parts: a radioresource control (RRC) connection and an S1-MME connection.

FIG. 4 is a diagram illustrating example network states of a clientdevice maintained at various entities in a network 400. As shown in FIG.4, network 400 includes a client device 402, a network access node 404,and an Evolved Packet Core (EPC) 406. As further shown in FIG. 4, theEPC 406 includes a home subscriber server (HSS) 412, a mobilitymanagement entity (MME) 408, and a Packet Data Network Gateway(P-GW)/Serving Gateway (S-GW) 410. In an aspect of the presentdisclosure, the network 400 may be a 4G network. In other aspects, thenetwork 400 may be a 3G network, an LTE network, a 5G network, or otherappropriate network.

For example, with reference to FIG. 4, the network access node 404 maymaintain a context 414 (also referred to as network state information)for the client device 402 when the client device 402 is in a connectedstate. The MME 408 may maintain a context 416 for the client device 402when the client device 402 is in a connected state, and a context 418for the client device 402 when the client device 402 is in an idlestate. The P-GW/S-GW 410 may maintain a context 426 for the clientdevice 402 when the client device 402 is in a connected state, and acontext 428 for the client device 402 when the client device 402 is inan idle state. The HSS 412 may maintain a context 420 for the clientdevice 402 when the client device 402 is in a connected state, a context422 for the client device 402 when the client device 402 is in an idlestate, and a context 424 for the client device 402 when the clientdevice 402 is in a deregistered state. In an aspect of the presentdisclosure, if the network 400 is implemented as a 3G network, theP-GW/S-GW 410 may not maintain a context for the client device 402 whenthe client device 402 is in the idle state.

In an aspect of the present disclosure, an encrypted client devicecontext may be generated for network functions, such as the IoTF-C 106and IoTF-U 108 in FIG. 1, to enable opportunistic reconstruction of acontext for a client device (also referred to as a client devicecontext). For example, an encrypted client device context may enable anetwork entity to reconstruct a client device context while maintainingminimal to no network state information for the client device.Therefore, the encrypted client device context may enable a networkentity to reconstruct a client device context without storing or cachingany network state information. It should be noted that in the presenceof potentially billions of client devices that transmit trafficinfrequently, it is not desirable for network functions (e.g., the MME408, the P-GW/S-GW 410) to maintain contexts (including securitycontexts) for client devices. Also, the encrypted client device contextmay eliminate signaling overhead at the network access node (e.g., eNB,base station, or network access point) during a handover or duringtransition from idle mode to connected mode. The encrypted client devicecontext may be used to substantially reduce or eliminate signalingoverhead since communication with an MME/controller may be avoided.

User Plane Encrypted Client Device Context

In an aspect of the present disclosure, a user plane (UP) encryptedclient device context may be generated for a client device. For example,with reference to FIG. 1, the user plane encrypted client device contextmay be used at the IoTF-U 108 for uplink (UL) data transmissions. In anaspect of the present disclosure, the user plane encrypted client devicecontext may include bearer IDs, Evolved Packet System (EPS) bearerquality of service(s) (QoS), an S5 tunnel endpoint identifier (TEID) fora user plane General Packet Radio Service (GPRS) tunneling protocol(GTP-U), a P-GW Internet Protocol (IP) address (or equivalentinformation) to which the IoTF-U 108 forwards UL data, and/or a securitycontext (e.g., a selected encryption algorithm and a user-plane (UP) key128). In other aspects, the user plane encrypted client device contextmay include other parameters, values, settings, or features that may beneeded by the network to provide a service to the client device. In oneexample, the UP key 128 may be the key K_(UP) 214, from which the keyK_(IoT-UPenc) 216 and the key K_(IoT-UPint) 218 may be derived. The userplane encrypted client device context may be generated by encrypting auser plane context for the client device using a secret key of theIoTF-U 108, such as the key K_(CDC-IoTF-U) 306 shown in FIG. 3. In anaspect of the present disclosure, the secret key of the IoTF-U 108, suchas the key K_(CDC-IoTF-U) 306, may be provisioned by IoTF-C 106. Theuser plane encrypted client device context may be decrypted by an IoTFthat has the secret key (e.g., the key K_(CDC-IoTF-U) 306). Accordingly,a user plane encrypted client device context may be decrypted by theIoTF that generated the user plane encrypted client device context.

Control Plane Encrypted Client Device Context

A control plane (CP) encrypted client device context may be generated byencrypting a control plane client device context for control messages(e.g., control packets or messages including control packets). In anaspect, the control plane encrypted client device context may include aclient device identifier, the client device security context (e.g.,control plane keys, such as the key K_(IoT) (K_(ASME) equivalent), thekey K_(IoT-CPenc) 210, the key K_(IoT-CPint) 212), the client devicesecurity capabilities (e.g., Evolved Packet System Encryption Algorithm(EEA), Evolved Packet System Integrity Algorithm (EIA)), and/or the nexthop (S5/S8) configuration information. For example, the next hopconfiguration information may include an IoT server address, a P-GWaddress, and/or TEIDs. For example, with reference to FIG. 1, thecontrol plane client device context for control messages may beencrypted with a secret key of the IoTF-C 106, such as keyK_(CDC-IoTF-C) 304 shown in FIG. 3. The control plane encrypted clientdevice context may be decrypted by an IoTF that has the secret key(e.g., the key K_(CDC-IoTF-C) 304). Accordingly, an encrypted clientdevice context may be decrypted by the IoTF that generated the controlplane encrypted client device context.

Encrypted Network Reachability Context

A network reachability context (NRC) for a client device may beencrypted (e.g., by an IoTF) to generate an encrypted networkreachability context for downlink (DL) transmissions to the clientdevice. The encrypted network reachability context enables an IoTF(e.g., IoTF-C 106, IoTF-U 108) to remove a client device context whenthe client device becomes idle. For example, with reference to FIG. 1,the encrypted network reachability context may be provided to the IoTserver 122 or to the P-GW 124 that desires to communicate with theclient device 102. Therefore, in this example, the IoT networkarchitecture 100 does not need to maintain network state information forthe client device 102 or may reduce the amount of network stateinformation maintained for the client device 102. The IoT server 122 orthe P-GW 124 may provide the encrypted network reachability context whenit sends a DL data packet to the client device 102 to allow one or morenodes or entities (e.g., network access node 104) in the IoT networkarchitecture 100 to reconstruct the network reachability context.

Encrypted network reachability context(s) may include one or more of thefollowing features. In an aspect of the present disclosure, an encryptednetwork reachability context may provide a mobility feature by includingan identifier for retrieving the network side network state informationof the client device 102, a tracking area ID (TAI) list or equivalent todetermine where to page the client device 102, and timing information(e.g., to determine when to page the client device 102). In an aspect ofthe present disclosure, an encrypted network reachability context mayenable a context relocation procedure, such as a tracking area update(TAU) and optionally to obtain a new encrypted network reachabilitycontext and ID. In an aspect of the present disclosure, an encryptednetwork reachability context may include information extending beyondsecurity and may indicate how security context is managed.

In an aspect of the present disclosure, the IoTF-C 106 providesinformation (e.g., a TAI list) to one or more entities in the servicenetwork 110 (e.g., IoT server 122 or P-GW 124). Such one or moreentities in the service network 110 may then send the encrypted networkreachability context to other entities in the IoT network architecture100 to re-establish the context for the client device 102. The encryptednetwork reachability context(s) may be implemented for network initiatedtraffic. However, in some aspects involving client device initiatedtraffic or network initiated traffic, the IoTF 105 may maintain verylimited to no network state information for the client device 102. In anaspect of the present disclosure, the IoTF-C 106 may provide thelocation of client device 102 in terms of at least a TAI list, which maybe a portion of a network reachability context.

Initial Attach Procedure

FIG. 5 is a block diagram illustrating an initial attach procedure by aclient device in an IoT network architecture 500 in accordance withvarious aspects of the present disclosure. In some aspects, an attachprocedure as described herein is also referred to as a networkattachment procedure or a registration procedure.

As shown in FIG. 5, the IoT network architecture 500 includes a clientdevice 502 (also referred to as an IoT device), a network access node504 (e.g., eNB, base station, network access point), a network device505, a service network 510, and a home subscriber server(HSS)/authentication, authorization, and accounting (AAA) server 512. Inone aspect, the network device 505 may include one or more processingcircuits and/or other appropriate hardware configured to implement anIoTF. For example, an IoTF may include a control plane IoT Function(IoTF-C) 506 and a user plane IoT Function (IoTF-U) 508. In such aspect,the IoTF-C 506 may be implemented at a first network node 507 and theIoTF-U 508 may be implemented at a second network node 509. In oneaspect, the IoTF-C 506 and the IoTF-U 508 may be implemented at the samehardware platform, such that the IoTF-C 506 and the IoTF-U 508 eachrepresent an independent node in the architecture 500. In such aspect,for example, the IoTF-C 506 may be implemented at a first virtualmachine (e.g., a first operating system) provided on a hardware platform(e.g., the network device 505) and the IoTF-U 508 may be implemented ata second virtual machine (e.g., a second operating system) provided onthe hardware platform.

As shown in FIG. 5, the IoTF-C 506 is in communication with the networkaccess node 504 via a first S1 connection 516, and the IoTF-U 508 is incommunication with the network access node 504 via a second S1connection 514. In an aspect of the present disclosure, the servicenetwork 510 may include a number of entities, functions, gateways,and/or servers configured to provide various types of services. Forexample, the service network 510 may include a short message entity(SME) 518, a machine type communication interworking function (MTC-IWF)520, an IoT server 522, and/or a packet data network (PDN) gateway(P-GW) 524. It should be understood that the service network 510disclosed in FIG. 5 serves as one example and that in other aspects, theservice network 510 may include different types of entities, functions,and/or servers than those disclosed in FIG. 5.

As shown in FIG. 5, the client device 502 may transmit an attach request532 to the network, which may be received by the network access node504. In an aspect of the present disclosure, the attach request 532 mayindicate that the client device 502 is to attach as an IoT device (e.g.,or indicate a request to perform small (reduced) data transfer, orindicate that the client device is operating in a low power consumptionmode) and may indicate the home domain (e.g., HPLMN ID or fullyqualified domain name (FQDN)) from which the authentication informationshould be retrieved. The network access node 504 may forward the requestto the IoTF-C 506 to which it belongs.

The IoTF-C 506 may determine the address of the HSS/AAA server 512 fromthe home domain information provided by the client device 502 and maytransmit a request 534 for authentication information for the clientdevice 502 to the HSS/AAA server 512. The IoTF-C 506 may receive theauthentication information 535 from the HSS/AAA server 512.

The IoTF-C 506 may perform mutual authentication (e.g., an AKAprocedure) with the client device 502. During the AKA procedure, theIoTF-C 506 may receive AVs from the HSS/AAA server 512 through theauthentication information 535. For example, the AVs may contain a key(shown in FIG. 2 as the key K_(ASME) 206) from an Access SecurityManagement Entity (ASME). For example, the IoTF-C 506 may provide thekey K_(ASME) 206 to the client device 502 through the signal 536. Whenthe AKA procedure is completed, the IoTF-C 506 and the client device 502may derive CP key(s) 526, such as the key K_(CP) 208, the keyK_(IoT-CPenc) 210 and/or the key K_(IoT-CPint) 212, and may derive UPkey(s) 528, such as the key K_(UP) 214, the key K_(IoT-UPenc) 216 and/orthe key K_(IoT-UPint) 218, from the key K_(ASME) 206 or from the keyK_(IoT) 202. In some aspects, the IoTF-C 506 may transfer the key K_(UP)214 and the user plane encryption and integrity protection keys, such asthe key K_(IoT-UPenc) 216 and the key K_(IoT-UPint) 218, to the IoTF-U508 via the message 538.

In an aspect of the present disclosure, the IoTF-C 506 may generate oneor more encrypted client device contexts for the client device 502 byusing the context key 530 to encrypt a client device context. The IoTF-C506 may then transmit the one or more encrypted client device contextsto the client device 502. For example, the IoTF-C 506 may generate anencrypted client device context for the control plane and an encryptedclient device context for the user plane. In such example, the contextkey 530 may include a first context key (e.g., the key K_(CDC-IoTF-C)304) for generating an encrypted client device context for the controlplane and a second context key (e.g., the key K_(CDC-IoTF-U) 306) forgenerating an encrypted client device context for the user plane. In anaspect of the present disclosure, the IoTF-C 506 may provide one or moreof the context key(s) 530 to the IoTF-U 508. For example, the IoTF-C 506may transmit the second context key (e.g., the key K_(CDC-IoTF-U) 306)for generating the encrypted client device context for the user plane tothe IoTF-U 508 via the message 538. Accordingly, in some aspects, theIoTF-U 508 may include context key(s) 531 provided by the IoTF-C 506.

In an aspect of the present disclosure, the IoTF-C 506 may generate oneor more encrypted network reachability contexts for transmittingdownlink (DL) traffic to the client device 502 using the context key 530to encrypt a network reachability context. The IoTF-C 506 may thentransmit the one or more encrypted network reachability contexts to anetwork entity such as the IoT server 522 or P-GW 524. Exampleapproaches for generating one or more encrypted network reachabilitycontexts are discussed in detail herein. The IoTF-C 506 may send the keyK_(UP) 214, user plane encryption and integrity protection keys (e.g.,the key K_(IoT-UPenc) 216 and the key K_(IoT-UPint) 218), and a networkreachability context (NRC) encryption key for the user plane (e.g., thekey K_(NRC-IoTF-U) 312), to the IoTF-U 508 via the message 538.Accordingly, in some aspects, the IoTF-U 508 may include context key(s)531 (e.g., the key K_(NRC-IoTF-U) 312) provided by the IoTF-C 506.

FIG. 6 is a signal flow diagram 600 of an exemplary attach procedure bya client device in an IoT network architecture (e.g., IoT networkarchitecture 100, 500) in accordance with various aspects of the presentdisclosure. As shown in FIG. 6, the signal flow diagram 600 includes aclient device 602 (also referred to as an IoT device), a network accessnode 604 (e.g., eNB, base station, or network access point), an IoTF-C606 implemented at a network node 605, an IoTF-U 608 implemented at anetwork node 607, a service network 609, and a home subscriber server(HSS) 610. As shown in FIG. 6, the client device 602 may transmit arequest 612 (e.g., an RRC connection request) to the network access node604 in order to communicate with the network. The client device 602 mayreceive an RRC connection setup message 614, which may include asignaling radio bearer (SRB) configuration (e.g., an SRB1 configurationfor transmitting NAS messages over a dedicated control channel (DCCH)).The client device 602 may transmit an RRC connection setup completemessage 616 to the network access node 604. For example, the RRCconnection setup complete message 616 may indicate an attach request.The network access node 604 may transmit an initial client devicemessage 618 to the IoTF-C 606. The IoTF-C 606 may determine the addressof the HSS server 610 from the home domain information provided by theclient device 602, and may communicate 621 with the HSS 610. Forexample, the IoTF-C 606 may transmit a request for authenticationinformation for the client device 602 to the HSS server 610 and mayreceive the authentication information from the HSS server 610.

As shown in FIG. 6, the IoTF-C 606 may perform mutual authentication,such as an AKA procedure 620, with the client device 602. When the AKAprocedure 620 is completed, the IoTF-C 606 and the client device 602 mayderive control plane keys, such as the key K_(IoT-CPenc) 210 and/or keyK_(IoT-CPint) 212, from the key K_(ASME) 206 or from the key K_(IoT)202. The IoTF-C 606 and the client device 602 may further derive userplane keys, such as the key K_(IoT-UPenc) 216 and/or the keyK_(IoT-UPint) 218, from the key K_(ASME) 206 or from the key K_(IoT)202. In an aspect of the present disclosure, the IoTF-C 606 may generatea control plane encrypted client device context by encrypting a controlplane context for the client device 602 using the key K_(CDC-IoTF-C) 304and/or may generate a user plane encrypted client device context byencrypting a user plane context for the client device 602 using the keyK_(CDC-IoTF-U) 306. The IoTF-C 606 may transfer one or more keys (e.g.,user plane keys, such as the key K_(IoT-UPenc) 216 and/or the keyK_(IoT-UPint) 218, and/or the key K_(CDC-IoTF-U) 306) to the IoTF-U 608via the message 622.

The IoTF-C 606 may transmit an initial context set up request message624 with an encrypted client device context (e.g., a control planeencrypted client device context and/or user plane encrypted clientdevice context) to the client device 602. Therefore, the encryptedclient device context may include a client device context associatedwith the IoTF-C 606 and/or IoTF-U 608 of the IoTF, where the clientdevice context may be used for uplink data transmission by the clientdevice 602. In an aspect of the present disclosure, the encryption keyis only known to an IoTF (e.g., the client device security context maybe retrieved exclusively by the IoTF-C 606 and/or IoTF-U 608 of theIoTF). Accordingly, in such aspect, the encryption key may be theK_(CDC)-IoTF-U 306, which may be unknown to network entities outside ofthe IoTF 606, such as the network access node 604 or the client device602. In an aspect of the present disclosure, each encrypted clientdevice context corresponds to one data radio bearer (DRB).

In an aspect of the present disclosure, the IoTF-C 606 may transmit amessage 625 including an encrypted network reachability context to theservice network 609. In an aspect of the present disclosure, the IoTF-C606 may generate a control plane (CP) encrypted network reachabilitycontext by encrypting a control plane context for the client device 602using the key K_(NRC-IoTF-C) 310 and/or may generate a user plane (UP)encrypted network reachability context for the client device 602 byencrypting a user plane context for the client device 602 using the keyK_(NRC-IoTF-U) 312. Therefore, in one example, the IoTF-C 606 maytransmit the message 625 including an encrypted network reachabilitycontext (e.g., a CP encrypted network reachability context and/or a UPencrypted network reachability context) to the service network 609.Therefore, the encrypted network reachability context may include aclient device context (e.g., network state information) associated withthe IoTF-C 606 and/or IoTF-U 608 of the IoTF, where such client devicecontext may be used for downlink (DL) data transmission from the network(e.g., from an entity in the service network 609) to the client device602. In an aspect of the present disclosure, the encryption key is onlyknown to IoTFs (e.g., may be retrieved exclusively by the IoTF-C 606and/or IoTF-U 608 of the IoTF). In an aspect of the present disclosure,the IoTF-C 608 may allocate encrypted network reachability contexts to anetwork entity, such as an IoT server or a P-GW in the service network609.

The network access node 604 may transmit an RRC connectionreconfiguration message 626 to the client device 602. In an aspect ofthe present disclosure, the RRC connection reconfiguration message 626may include the encrypted client device context. The client device 602may transmit an RRC connection reconfiguration complete message 628 tothe network access node 604. The client device 602 may transmit a firstmessage 630 including a data packet (e.g., a UL data packet) to thenetwork access node 604. The network access node 604 may forward thedata packet to the service network 609 via the second message 632. Theservice network 609 may transmit a third message 634 including a datapacket (e.g., a DL data packet) to the client device 602. For example,and as shown in FIG. 6, the third message 634 may be forwarded to theclient device 602 by the IoTF-U 608 and the network access node 604. Theclient device 602 may then transition 636 to the idle mode. The networkaccess node 604, the IoTF-C 606, and the IoTF-U 608 may proceed toremove 638 the client device context.

IoT UL Data Transfer

FIG. 7 is a block diagram illustrating a data transmission initiated bya client device in an IoT network architecture 700 in accordance withvarious aspects of the present disclosure. As shown in FIG. 7, the IoTnetwork architecture 700 includes a client device 702 (also referred toas an IoT device), a network access node 704 (e.g., eNB, base station,network access point), a network device 705, a service network 710, anda home subscriber server (HSS)/authentication, authorization, andaccounting (AAA) server 712. In one aspect, the network device 705 mayinclude one or more processing circuits and/or other appropriatehardware configured to implement an IoTF. For example, an IoTF mayinclude a control plane IoT Function (IoTF-C) 706 and a user plane IoTFunction (IoTF-U) 708. In such aspect, the IoTF-C 706 may be implementedat a network node 707 and the IoTF-U 708 may be implemented at a networknode 709. In one aspect, the IoTF-C 706 and the IoTF-U 708 may beimplemented at the same hardware platform, such that the IoTF-C 706 andthe IoTF-U 708 each represent an independent node in the architecture700. In such aspect, for example, the IoTF-C 706 may be implemented at afirst virtual machine (e.g., a first operating system) provided on ahardware platform (e.g., the network device 705) and the IoTF-U 708 maybe implemented at a second virtual machine (e.g., a second operatingsystem) provided on the hardware platform.

In an aspect of the present disclosure, the service network 710 mayinclude a number of entities, functions, gateways, and/or serversconfigured to provide various types of services. For example, theservice network 710 may include a short message entity (SME) 718, amachine type communication interworking function (MTC-IWF) 720, an IoTserver 722, and/or a packet data network (PDN) gateway (P-GW) 724. Itshould be understood that the service network 710 disclosed in FIG. 7serves as one example and that in other aspects, the service network 710may include different types of entities, functions, and/or servers thanthose disclosed in FIG. 7.

In the aspect of FIG. 7, the IoTF-C 706 may have generated an encryptedclient device context for the control plane and an encrypted clientdevice context for the user plane. In such aspect, the context key(s)730 may include a first context key (e.g., the key K_(CDC-IoTF-C) 304)for generating an encrypted client device context for the control planeand a second context key (e.g., the key K_(CDC-IoTF-U) 306) forgenerating an encrypted client device context for the user plane. Forexample, the IoTF-C 706 may have transmitted the second context key(e.g., the key K_(CDC-IoTF-U) 306) for generating the encrypted clientdevice context for the user plane to the IoTF-U 708. Accordingly, insuch example, the IoTF-U 708 may include the context key(s) 731 providedby the IoTF-C 706 as shown in FIG. 7. In the aspect of FIG. 7, theclient device 702 has derived CP key(s) 726 and UP key(s) 728 in amanner previously discussed.

In the aspect of FIG. 7, the IoTF-C 706 may have generated an encryptednetwork reachability context for the control plane and an encryptednetwork reachability context for the user plane. In such aspect, thecontext key(s) 730 may include a first context key (e.g., the keyK_(NRC-IoTF-C) 310) for generating an encrypted network reachabilitycontext for the control plane and a second context key (e.g., the keyK_(NRC_IoTF-U) 312) for generating an encrypted network reachabilitycontext for the user plane. For example, the IoTF-C 706 may havetransmitted the second context key (e.g., the key K_(NRC-IoTF-U) 312)for generating the encrypted network reachability context for the userplane to the IoTF-U 708. Accordingly, in such example, the IoTF-U 708may include the context key(s) 731 provided by the IoTF-C 706 as shownin FIG. 7.

As shown in FIG. 7, the client device 702 may transmit a first message732 including a data packet and an encrypted client device contextprovided by the IoTF-C 706 to the network access node 704. The datapacket in the first message 732 may be encrypted and integrity protectedbased on the user plane (UP) keys 728. The network access node 704 maydetermine the address of the IoTF-U 708 from the IoTF-U identifier inthe data packet and may forward the data packet to the IoTF-U 708 via asecond message 734. In an aspect, the network access node 704 mayforward the data packet to the next hop node (e.g., the IoTF-U 708)indicated by the client device 702 without verifying the packet. TheIoTF-U 708 may verify the encrypted client device context and maydecrypt the encrypted client device context using the context key(s) 731(e.g., the key K_(CDC-IoTF-U) 306 for generating the encrypted clientdevice context for the user plane). The IoTF-U 708 may reconstruct theclient device context based on the decrypted information. The IoTF-U 708may then decrypt and verify the data packet with the encryption andintegrity keys (e.g., UP key(s) 728). In an aspect of the presentdisclosure, the IoTF-U 708 may generate an encrypted networkreachability context based on the context (e.g., network stateinformation) of the client device 702. The IoTF-U 708 may forward thedata packet via a third message 736 to the next hop (e.g., the IoTserver 722 or the P-GW 724) with the encrypted network reachabilitycontext. In an aspect of the present disclosure, initial data transferby the client device 702 immediately following an attach procedure maynot carry the encrypted client device context.

FIG. 8 is a signal flow diagram 800 illustrating an exemplary datatransmission initiated by a client device in an IoT network architecture(e.g., IoT network architecture 700) in accordance with various aspectsof the present disclosure. As shown in FIG. 8, the signal flow diagram800 includes a client device 802 (also referred to as an IoT device), anetwork access node 804 (e.g., eNB, base station, or network accesspoint), an IoTF-U 806 implemented at a network node 805, and a servicenetwork 808. The client device 802 may transmit a data transfer requestmessage 810 that includes an encrypted client device context and a datapacket (e.g., a UL data packet) to the network access node 804. The datapacket may be encrypted and integrity protected based on the previouslydiscussed user plane keys (e.g., the key K_(IoT-UPenc) 216 and/or thekey K_(IoT-UPint) 218). In as aspect, the data transfer request message810 may be sent by the client device 802 without establishing an RRCconnection with the network access node 804. The network access node804, upon receipt of the data transfer request message 810, may assign812 a temporary identifier (TID) for the client device 802 for potentialdownlink (DL) traffic. For example, the TID may be a cell radio networktemporary identifier (C-RNTI). The network access node 804 may determinethe IoTF-U identifier included in the header of the data packet. Anexample format of the data packet including such header is discussedherein with reference to FIG. 12. The network access node 804 maydetermine the IP address of the IoTF-U 806, and may forward the datapacket to the IoTF-U 806 via a first message 814. For example, as partof the Operations and Maintenance (OAM) procedures, the network accessnode 804 may be configured with a set of IoTF-U identifiers and thecorresponding IP address, or alternatively, the network access node 804may use a domain name system (DNS) query based on the IoTF-U ID todetermine the IP address of the IoTF-U 806. In an aspect of the presentdisclosure, and as shown in FIG. 8, the network access node 804 mayinclude the TID and the encrypted client device context along with thedata packet in the first message 814. In an aspect of the presentdisclosure, the TID is stored at the network access node 804 for apredefined time interval. In such aspect, the network access node 804may transmit the TID expiration time to IoTF-U 806 along with the TID inthe first message 814. The IoTF-U 806 may decrypt the encrypted clientdevice context and may reconstruct 816 the client device context (e.g.,S5 bearer). In an aspect, the IoTF-U 806 may then decrypt and verify thedata packet with the encryption and integrity keys (e.g., UP key(s)728).

The IoTF-U 806 may forward the data packet to the service network 808(e.g., the P-GW in service network 808 or other entity in the servicenetwork 808) via a second message 818. In response to the uplink data(e.g., the UL data packet in the second message 818), the IoTF-U 806 mayreceive a data packet (e.g., a DL data packet) from the service network808 (e.g., the P-GW in the service network 808 or a corresponding entityin the service network 808) via the third message 820. The IoTF-U 806may determine one or more keys associated with the client device 802(e.g., the user plane key(s) 728). For example, the IoTF-U 806 mayencrypt and integrity protect the data packet for the client device withthe keys K_(IoT-UPenc) 216 and/or the key K_(IoT-UPint) 218 associatedwith the client device 802. The IoTF-U 806 may transmit the receiveddata packet to the network access node 804 with the TID in a fourthmessage 822. The network access node 804 may identify the client device802 using the TID and may transmit the data packet to the client device802 in a fifth message 824. The client device 802 may transition 826 tothe idle mode based on a pre-configured timer. The network access node804 and the IoTF-U 806 may proceed to remove 828 the client devicecontext that was created on-the-fly from the encrypted client devicecontext.

Client Device Terminated Data Transfer

FIG. 9 is a signal flow diagram 900 of an exemplary client deviceterminated data transmission in an IoT network architecture (e.g., IoTnetwork architecture 100) in accordance with various aspects of thepresent disclosure. As shown in FIG. 9, the signal flow diagram 900includes a client device 902 (also referred to as an IoT device), anetwork access node 904 (e.g., eNB, base station, network access point),an IoTF-C 906 implemented at a network node 905 and an IoTF-U 908implemented at a network node 907, a P-GW 910, and an IoT server 912.

The IoT server 912 may transmit a downlink (DL) message 914 including aDL data packet, a global IoTF identifier (GIOTFI), and an encryptednetwork reachability context (NRC) to the P-GW 910. The P-GW 910 maylocate the IoTF-U 908 based on the GIOTFI and may forward the DL datapacket to the IoTF-U 908 in a forward message 916. In an aspect of thepresent disclosure, the IoTF-U 908 may verify the encrypted networkreachability context. As shown in FIG. 9, the IoTF-U 908 may reconstruct917 the context for the client device 902. For example, the IoTF-U 908may reconstruct the context for the client device 902 by decrypting theencrypted network reachability context using a context key (e.g., thekey K_(NRC-IoTF-U) 312) stored at the IoTF-U 908.

The IoTF-U 908 may transmit a DL data notification message 918 to theIoTF-C 906. In an aspect of the present disclosure, the DL datanotification message 918 may include the DL data packet if the DL datapacket is small enough to be carried in a paging message. The IoTF-C 906may transmit a paging message 920 to one or more network access nodes(e.g., network access node 904). The network access node 904 may thenpage the client device 902 by transmitting the page message 922.

The client device 902 may transmit an RRC connection request message 924including a UL data packet to the IoTF-U 908. In an aspect of thepresent disclosure, the UL data packet transmitted by the client device902 may be empty. The network access node 904 may assign 926 a temporaryidentifier (TID) for the client device 902 for potential downlink (DL)traffic. For example, the TID may be a cell radio network temporaryidentifier (C-RNTI). The network access node 904 may then forward the ULdata packet with the TID and encrypted client device context to theIoTF-U 908 in a forward message 928. The IoTF-U 908 may store 930 theTID and ID of the network access node 904.

The IoTF-U 908 may transmit a client device response notificationmessage 932 to the IoTF-C 906. In an aspect of the present disclosure,the IoTF-U 908 may transmit, to the client device 902, a message 934including a DL data packet and the TID for the client device 902 if theIoTF-U 908 was not able to include the DL data packet in the DL datanotification message 918. The network access node 904 may forward the DLdata packet to the client device 902 in a forward message 936. Theclient device 902 may then transition 938 to the idle mode. The networkaccess node 904 and IoTF-C 906 may remove 940 the client device context.

Control Plane Protocol Stack

FIG. 10 is a diagram illustrating a control plane protocol stack 1000for IoT data transmission in accordance with various aspects of thepresent disclosure. As shown in FIG. 10, the protocol stack 1000 mayinclude a client device protocol stack 1002 (also referred to as an IoTdevice protocol stack), a network access node protocol stack 1004, anIoTF protocol stack 1006 implemented at a network node 1005, and aservice network protocol stack 1008. For example, the network accessnode protocol stack 1004 may be implemented in an eNB, base station, ornetwork access point. As another example, service network protocol stack1008 may be implemented in a P-GW. As shown in FIG. 10, the clientdevice protocol stack 1002 may include a physical (PHY) layer 1010, amedia access control (MAC) layer 1012, a radio link control (RLC) layer1014, a packet data convergence protocol (PDCP) layer 1016, and acontrol (Ctrl) layer 1020. As further shown in FIG. 10, the clientdevice protocol stack 1002 may implement a context protocol layer 1018for communicating a control plane encrypted client device context(abbreviated as “CDC_(CP)” in FIG. 10). The context protocol layer 1018may further enable communication of an IoTF ID (IID) and/or a securityheader (abbreviated as “Sec” in FIG. 10) that indicates the presence ofan encrypted client device context.

As shown in FIG. 10, the network access node protocol stack 1004 mayinclude a PHY layer 1022, a MAC layer 1024, an RLC layer 1026, and aPDCP layer 1028 that respectively interface with the PHY layer 1010, theMAC layer 1012, the RLC layer 1014, and the PDCP layer 1016 of theclient device protocol stack 1002. The network access node protocolstack 1004 may further include an Ethernet layer 1030, a MAC layer 1032,an Internet Protocol (IP) layer 1034, a user datagram protocol (UDP)layer 1036, and a control plane GPRS Tunneling Protocol (GTP-C) layer1038.

As shown in FIG. 10, the IoTF protocol stack 1006 may include anEthernet layer 1040, a MAC layer 1042, an IP layer 1044, a UDP layer1046, a GTP-C layer 1048, and a control (Ctrl) layer 1052. As furthershown in FIG. 10, the IoTF protocol stack 1006 may implement a contextprotocol layer 1050 for communicating a control plane encrypted clientdevice context (abbreviated as “CDC_(CP)” in FIG. 10). The contextprotocol layer 1050 may also enable communication of an IoTF ID (IID)and/or a security header (abbreviated as “Sec” in FIG. 10) thatindicates the presence of an encrypted client device context. As shownin FIG. 10, the context protocol layer 1018 of the client deviceprotocol stack 1002 is in communication with the context protocol layer1050 of the IoTF protocol stack 1006. In an aspect, an encrypted clientdevice context may be carried in a packet header outside a UP message inaccordance with the exemplary packet format described with respect toFIG. 12. As further shown in FIG. 10, the IoTF protocol stack 1006 mayfurther implement a context protocol layer 1049 for communicating acontrol plane encrypted network reachability context (abbreviated as“NRC_(CP)” in FIG. 10). The context protocol layer 1049 may also enablecommunication of an IoTF ID (IID) and/or a security header (abbreviatedas “Sec” in FIG. 10) that indicates the presence of an encrypted networkreachability context.

The service network protocol stack 1008 may include an IP layer 1054, aUDP layer 1056, a GTP-C layer 1058, and a Ctrl layer 1062 thatrespectively interface with the IP layer 1044, the UDP layer 1046, theGTP-C layer 1048 and the Ctrl layer 1052 of the IoTF protocol stack1006. As further shown in FIG. 10, the service network protocol stack1008 may implement a context protocol layer 1059 for communicating acontrol plane encrypted network reachability context (abbreviated as“NRC_(CP)” in FIG. 10). The context protocol layer 1059 may also enablecommunication of an IoTF ID (IID) and/or a security header (abbreviatedas “Sec” in FIG. 10) that indicates the presence of an encrypted networkreachability context. As shown in FIG. 10, the context protocol layer1059 of the service network protocol stack 1008 is in communication withthe context protocol layer 1049 of the IoTF protocol stack 1006. In anaspect of the present disclosure, an encrypted network reachabilitycontext may be carried in a packet header outside a user plane messagein accordance with the exemplary packet format described with respect toFIG. 13. In an aspect of the present disclosure, if a networkarchitecture is implemented as a GSM EDGE Radio Access Network (GERAN),protocols different than the IP protocols 1066 may be used. In an aspectof the present disclosure, the GTP-C and UDP protocols indicated byregions 1064 and 1068 may be omitted.

User Plane Protocol Stack

FIG. 11 is a diagram illustrating a user plane protocol stack 1100 forIoT data transmission in accordance with various aspects of the presentdisclosure. As shown in FIG. 11, the protocol stack 1100 may include aclient device protocol stack 1102 (also referred to as an IoT deviceprotocol stack), a network access node protocol stack 1104, an IoTFprotocol stack 1106 implemented at a network node 1105, and a servicenetwork protocol stack 1108. For example, the network access nodeprotocol stack 1104 may be implemented in an eNB, base station, ornetwork access point. As another example, the service network protocolstack 1108 may be implemented in a P-GW. As shown in FIG. 11, the clientdevice protocol stack 1102 may include a physical (PHY) layer 1110, amedia access control (MAC) layer 1112, a radio link control (RLC) layer1114, a packet data convergence protocol (PDCP) layer 1116, and a userplane (UP) layer 1120. As further shown in FIG. 11, the client deviceprotocol stack 1102 may implement a context protocol layer 1118 forcommunicating a user plane encrypted client device context (abbreviatedas “CDC_(UP)” in FIG. 11). The context protocol layer 1118 may furtherenable communication of an IoTF ID (IID) and/or a security header(abbreviated as “Sec” in FIG. 101) that indicates the presence of anencrypted client device context.

As shown in FIG. 11, the network access node protocol stack 1104 mayinclude a PHY layer 1122, a MAC layer 1124, an RLC layer 1126, and aPDCP layer 1128 that respectively interface with the PHY layer 1110, theMAC layer 1112, the RLC layer 1114, and the PDCP layer 1116 of theclient device protocol stack 1102. The network access node protocolstack 1104 may further include an Ethernet layer 1130, a MAC layer 1132,an Internet Protocol (IP) layer 1134, a user datagram protocol (UDP)layer 1136, and a user plane GPRS Tunneling Protocol (GTP-U) layer 1138.

As shown in FIG. 11, the IoTF protocol stack 1106 may include anEthernet layer 1140, a MAC layer 1142, an IP layer 1144, a UDP layer1146, and a GTP-U layer 1148. As further shown in FIG. 11, the IoTFprotocol stack 1106 may implement a context protocol layer 1150 forcommunicating a user plane encrypted client device context (abbreviatedas “CDC_(UP)” in FIG. 11). The context protocol layer 1150 may alsoenable communication of an IoTF ID (IID) and/or a security header(abbreviated as “Sec” in FIG. 11) that indicates the presence of anencrypted client device context. As shown in FIG. 11, the contextprotocol layer 1118 of the client device protocol stack 1102 is incommunication with the context protocol layer 1150 of the IoTF protocolstack 1106. In an aspect, a user plane encrypted client device contextmay be carried in a packet header outside a UP message in accordancewith the exemplary packet format described with respect to FIG. 12. Asfurther shown in FIG. 11, the IoTF protocol stack 1106 may furtherimplement a context protocol layer 1149 for communicating a user planeencrypted network reachability context (abbreviated as “NRC_(UP)” inFIG. 11). The context protocol layer 1149 may also enable communicationof an IoTF ID (IID) and/or a security header (abbreviated as “Sec” inFIG. 11) that indicates the presence of an encrypted networkreachability context.

The service network protocol stack 1108 may include an IP layer 1154, aUDP layer 1156, a GTP-U layer 1158 and a UP layer 1162 that respectivelyinterface with the IP layer 1144, the UDP layer 1146, the GTP-U layer1148, and the UP layer 1152 of the IoTF protocol stack 1106. The servicenetwork protocol stack 1108 may implement a context protocol layer 1159for communicating a user plane encrypted network reachability context(abbreviated as “NRC_(UP)” in FIG. 11). As shown in FIG. 11, the contextprotocol layer 1159 of the service network protocol stack 1108 is incommunication with the context protocol layer 1149 of the IoTF protocolstack 1106. In an aspect of the present disclosure, a user planeencrypted network reachability context may be carried in a packet headeroutside a UP message in accordance with the exemplary packet formatdescribed with respect to FIG. 11. In an aspect of the presentdisclosure, if a network architecture is implemented as a GSM EDGE RadioAccess Network (GERAN), protocols different than the IP protocols 1166may be used. In an aspect of the present disclosure, the GTP-U and UDPprotocols indicated by regions 1164 and 1168 may be omitted. In anaspect of the present disclosure, if the IP protocol is used for UPmessage delivery, the user plane encrypted network reachability contextmay be carried in the IP options field (IPv4) or IP extension header(IPv6).

IoT Packet Format

FIG. 12 is a diagram of a packet format 1200 for transmissions in an IoTnetwork architecture in accordance with various aspects of the presentdisclosure. With reference to FIG. 12, the temporary identifier (TID)field 1202 may be used by a network access node (e.g., eNB, basestation, or network access point) to identify a client device (alsoreferred to as an IoT device) locally. For example, the value assignedby a network access node to the TID field 1202 for identifying a clientdevice may be a C-RNTI or equivalent. In an aspect of the presentdisclosure, the IoTF ID (IID) field 1204 may include a globally uniquetemporary identifier (GUTI). For example, the GUTI may include anidentifier associated with an IoTF and an identifier (e.g., a temporaryidentifier, such as a mobility management entity (MME) temporary mobilesubscriber identity (M-TMSI)) associated with the client device. Forexample, the GUTI may be used by a network access node to identify anIoTF, and the GUTI may be used by an IoTF to identify a client device.In another aspect, the IID field 1204 may include a global IoTFidentifier (GIOTFI) and an identifier (e.g., a temporary identifier,such as an M-TMSI) associated with the client device. For example, theGIOTFI may be an equivalent of a globally unique mobility managemententity identifier (GUMMEI) for an IoTF. In an aspect of the presentdisclosure, the M-TMSI may be encrypted for client device privacy. Itshould be noted that using the IoTF IP address may disclose the networktopology.

The security header field 1206 may indicate the presence of an encryptedclient device context, a control plane (CP)/user plane (UP) indication,a sequence number, a time stamp value and/or a random value. Forexample, the time stamp value may be based on a time and a counter,where the time is the network access node time or IoTF time. The clientdevice context field 1208 may include an encrypted client devicecontext. It should be noted that if a time stamp is used for encryptioninstead of the sequence number, the IoTF may not need to maintain anyclient device network states. In an aspect, a random value may be basedon a random number and a counter. The random value may be generated bythe network access node or by the client device, or a combinationthereof. The counter may be incremented by a certain value (e.g., one)for each packet. If a random value is used for encryption instead of thesequence number, the client device may generate a new encryption keybased on the encryption key in the security context and the randomnumber. If a random value is used for integrity protection instead ofthe sequence number, the client device may generate a new integrityprotection key based on the integrity protection key in the securitycontext and the random number, and may protect a message using the newintegrity protection key. The payload field 1210 may include data orcontrol information (e.g., a data packet or a control packet).

The message authentication code (MAC) field 1212 may be used forintegrity protection. For example, the MAC field 1212 may include amessage authentication code generated by a transmitting device orentity. The message authentication code in the MAC field 1212 may thenbe used by a receiving device or entity to verify that the integrity ofthe message has not been compromised (e.g., that the contents of themessage have not been altered or manipulated). In one aspect, themessage authentication code in the MAC field 1212 may be generated at atransmitting device or entity by applying a message authentication codegeneration algorithm (e.g., an AEAD cihper), where a message (e.g., apacket) and a user plane key or a control plane key are used as inputsfor the message authentication code generation algorithm. The output ofthe message authentication code generation algorithm may be the messageauthentication code included in the MAC field 1212. A receiving deviceor entity may verify the integrity of the received message by applyingthe message authentication code generation algorithm (e.g., the AEADcihper) to the message. For example, the received message (e.g., thepacket) and the user plane key or the control plane key may be used asinputs for the message authentication code generation algorithm. Thereceiving device or entity may then compare the output of the messageauthentication code generation algorithm to the message authenticationcode included in the MAC field 1212. In such example, when the output ofthe message authentication code generation algorithm matches the messageauthentication code included in the MAC field 1212, the receiving deviceor entity may determine that the message has been successfully verified.

FIG. 13 is a diagram of a packet format 1300 for transmissions in an IoTnetwork architecture in accordance with various aspects of the presentdisclosure. With reference to FIG. 13, the temporary identifier (TID)field 1302 may be used by a network access node (e.g., eNB, basestation, or network access point) to identify a client device (alsoreferred to as an IoT device) locally. For example, the value assignedby a network access node to the TID field 1302 for identifying a clientdevice may be a C-RNTI or equivalent. In an aspect of the presentdisclosure, the IoTF ID (IID) field 1304 may include a globally uniquetemporary identifier (GUTI) or a global IoTF identifier (GIOTFI). Forexample, the GUTI may be used by a network access node to identify anIoTF, and the GUTI may be used by an IoTF to identify a client device.For example, the GIOTFI may be an equivalent of a globally uniquemobility management entity identifier (GUMMEI) for an IoTF. In an aspectof the present disclosure, a mobility management entity (MME) temporarymobile subscriber identity (M-TMSI) may be encrypted for client deviceprivacy. It should be noted that using the IoTF IP address may disclosethe network topology. The security header field 1306 may indicate thepresence of an encrypted network reachability context, a CP/UPindication, a sequence number, and/or or a time stamp value. Forexample, the time stamp value may be based on a time and a counter,where the time is the network access node time or IoTF time. The networkreachability context field 1308 may include an encrypted networkreachability context. The payload field 1310 may include data or controlinformation (e.g., a data packet or a control packet). The messageauthentication code (MAC) field 1312 may be used for integrityprotection (e.g., an AEAD cipher may be used). It should be noted thatif a time stamp is used for encryption instead of the sequence number,the IoTF may not need to maintain any network state information for aclient device.

Encrypted Client Device Context Design and Generation

In an aspect of the present disclosure, the encrypted client devicecontext may contain the client device context established during an AKAprocedure. For example, the client device context may include a securitycontext, a bearer ID, Evolved Packet System (EPS) bearer quality ofservice(s) (QoS) and S5-TEID(s), and/or other services, parameters,values, settings, or features that may be needed by the network toprovide a service to the client device.

In some aspects, the encrypted client device context may include one ormore items of information in addition to the client device context. Forexample, the encrypted client device context may include an expirationtime set by IoTF-C 106 (or indicated in the client device context),which limits the lifetime of the encrypted client device context (e.g.,to prevent permanent reuse). As another example, the encrypted clientdevice context may have a key index that identifies the key used forgenerating the encrypted client device context.

In some aspects, the encrypted client device context may be generatedusing a secret key that is only known to an entity in the network and,therefore, may not be interpreted and/or modified by client devices. Forexample, the encrypted client device context may be generated byencrypting a client device context using the secret key of the IoTF-U(e.g., IoTF-U 108). In some aspects, the encrypted client device contextmay be integrity protected with the secret key of the IoTF-U (e.g.,IoTF-U 108) and, therefore, may not be manipulated/modified by clientdevices.

In an aspect, the encrypted client device context may be provided to aclient device (e.g., client device 102) by the IoTF-C (e.g., IoTF-C 106)as a successful completion of authentication and context (e.g., bearer)setup. In an aspect, a client device may include the encrypted clientdevice context in one or more user plane packets (e.g., UL data packets)to enable the IoTF-U (e.g., IoTF-U 108) to reconstruct the client devicecontext on-the-fly. For example, if a client device needs to transmitmultiple packets in series, the client device may include the encryptedclient device context in the first packet without including theencrypted client device context in subsequent packets. In some aspects,the encrypted client device context may be specific to a client deviceand, therefore, an encrypted client device context issued to a clientdevice may not be used by any other client devices.

a) Control Plane Encrypted Client Device Context

In an aspect of the present disclosure, an IoTF (e.g., IoTF-C 106 inFIG. 1) may generate an encrypted client device context by concatenatingone or more items of information. For example, a control plane (CP)encrypted client device context (CDC_(CP)) may be generated based on theexpression KeyID∥Enc_K_(CDC-IoTF-C) (CDC_(CP))∥MAC. In an aspect of thepresent disclosure, the key K_(CDC-IoTF-c) (e.g., the key K_(CDC-IoTF-C)304 in FIG. 3) may be the same as the key K_(CDC-IoTF) (e.g., the keyK_(CDC-IoTF) 302 in FIG. 3) or derived from the key K_(CDC-IoTF). Theterm KeyID may represent the Key Index (used for generating theencrypted client device context).

The term CDC_(CP) may represent the control plane client device context.For example, the control plane client device context may include aclient device identifier, the client device security context (e.g.,control plane keys, such as the key K_(IoT) (K_(ASME) equivalent), thekey K_(IoT-CPenc) 210, the key K_(IoT-CPint) 212), the client devicesecurity capabilities (e.g., Evolved Packet System Encryption Algorithm(EEA), Evolved Packet System Integrity Algorithm (EIA)), and/or the nexthop (S5/S8) configuration information. For example, the next hopconfiguration information may include an IoT server address, a P-GWaddress, and/or TEIDs. The term MAC may indicate the encryption modeand/or a message authentication code generation algorithm (also referredto as a MAC algorithm), which may be chosen by a mobile network operator(MNO) and configured to IoTFs. Therefore, the term Enc_K_(CDC-IoTF-C)(CDC_(CP)) may represent the result of an encryption operation performedon the control plane client device context using the key K_(CDC-IoTF-C).

b) User Plane Encrypted Client Device Context

As another example, a user plane (UP) encrypted client device context(CDC_(UP)) may be generated based on the expressionKeyID∥Enc_K_(CDC-IoTF-U) (CDC_(UP))∥MAC. The term CDC_(UP) may representthe user plane client device context. For example, the user plane clientdevice context may include a client device identifier, bearer IDs,Evolved Packet System (EPS) bearer quality of service(s) (QoS), an S5tunnel endpoint identifier (TEID) for a user plane General Packet RadioService (GPRS) tunneling protocol (GTP-U), a P-GW Internet Protocol (IP)address (or equivalent information) to which the IoTF-U 108 forwards ULdata, a client device security context (e.g., a selected encryptionalgorithm and user plane keys, such as the key K_(IoT-UPenc) 216, thekey K_(IoT-UPint) 218), the client device security capabilities (e.g.,Evolved Packet System Encryption Algorithm (EEA), Evolved Packet SystemIntegrity Algorithm (EIA)), and/or the next hop (S5/S8) configurationinformation. For example, the next hop configuration information mayinclude an IoT server address, a P-GW address, and/or TEIDs. Therefore,the term Enc_K_(CDC-IoTF-U) (CDC_(UP)) may represent the result of anencryption operation performed on the user plane client device contextusing the key K_(CDC-IoTF-U). In an aspect of the present disclosure,the encrypted client device context may only be decrypted by the IoTF(e.g., IoTF-C 106 and/or IoTF-U 108) to which the client device isattached/associated. In an aspect of the present disclosure, a clientdevice context may be compressed before being encrypted.

The encrypted client device context may have one or morecharacteristics. For example, an encrypted client device context maycontain the network state information associated with a particularclient device and, therefore, may not be transferrable to other clientdevices. An IoTF-C/U (e.g., the IoTF-C 106 and/or the IoTF-U 108) maynot maintain contexts (e.g., network state information) of a clientdevice. Accordingly, such IoTF-C/U may recover a client device contextfrom an encrypted client device context using its own secret key and,therefore, the IoTF-C/U may not need to store any additional informationto recover a client device context. The IoTF-C/U may remove a clientdevice context under certain conditions (e.g., Evolved Packet SystemConnection Management (ECM)-Idle or immediately after small datatransfer) and restore it when necessary (e.g., for data transfer).

A client device may store encrypted client device contexts provided byan IoTF-C for fast UL data transfer/fast control plane message transfer.The client device may enter a sleep mode immediately after transmittingone or more data packet(s). Since there may be no message exchangeoverhead for an IoTF-U to reconstruct a client device context, no delaymay be experienced for transmission of small data packets. In an aspectof the present disclosure, no control plane message may be used for userplane data transmission when the client device is in the idle mode.

Encrypted Network Reachability Context Design and Generation

a) Control Plane Encrypted Network Reachability Context

In an aspect of the present disclosure, an encrypted networkreachability context may be generated by concatenating one or more itemsof information. For example, a control plane (CP) encrypted networkreachability context may be generated based on the expressionKeyID∥Enc_K_(NRC-IoTF-C) (CDC_(CP))∥MAC. In an aspect of the presentdisclosure, the key K_(NRC-IoTF-C) (e.g., the key K_(NRC-IoTF-C) 310 inFIG. 3) may be the same as the key K_(NRC-IoTF) (e.g., the keyK_(NRC-IoTF) 308 in FIG. 3) or may be derived from the key K_(NRC-IoTF).The term KeyID may represent the Key Index (used for generating thenetwork reachability context). The term CDC_(CP) may represent thecontrol plane client device context. For example, the control planeclient device context may include a client device identifier, the clientdevice security context (e.g., control plane keys, such as the keyK_(IoT) 202 (K_(ASME) equivalent), the key K_(IoT-CPenc) 210, the keyK_(IoT-CPint) 212), the client device security capabilities (e.g.,Evolved Packet System Encryption Algorithm (EEA), Evolved Packet SystemIntegrity Algorithm (EIA)), and/or the next hop (S5/S8) configurationinformation. For example, the next hop configuration information mayinclude an IoT server address, a P-GW address, and/or TEIDs. The termMAC may indicate the encryption mode and/or a message authenticationcode generation algorithm (also referred to as a MAC algorithm), whichmay be chosen by a mobile network operator (MNO) and configured toIoTFs. Therefore, the term Enc_K_(NRC-IoTF-C) (CDC_(CP)) may representthe result of an encryption operation performed on the control planeclient device context using the key K_(NRC-IoTF-C) (e.g., the keyK_(NRC-IoTF-C) 310 in FIG. 3).

b) User Plane Encrypted Network Reachability Context

As another example, a user plane (UP) encrypted network reachabilitycontext may be generated based on the expressionKeyID∥Enc_K_(NRC-IoTF-U) (CDC_(UP))∥MAC. The term CDC_(UP) may representthe user plane client device context. For example, the user plane clientdevice context may include a client device identifier, bearer IDs,Evolved Packet System (EPS) bearer quality of service(s) (QoS), an S5tunnel endpoint identifier (TEID) for a user plane General Packet RadioService (GPRS) tunneling protocol (GTP-U), a P-GW Internet Protocol (IP)address (or equivalent information) to which the IoTF-U 108 forwards ULdata, a client device security context (e.g., a selected encryptionalgorithm and user plane keys, such as the key K_(IoT-UPenc) 216, thekey K_(IoT-UPint) 218), the client device security capabilities (e.g.,Evolved Packet System Encryption Algorithm (EEA), Evolved Packet SystemIntegrity Algorithm (EIA)), and/or the next hop (S5/S8) configurationinformation. For example, the next hop configuration information mayinclude an IoT server address, a P-GW address, and/or TEIDs. Therefore,the term Enc_K_(NRC-IoTF-U) (CDC_(UP)) may represent the result of anencryption operation performed on the user plane client device contextusing the key K_(NRC-IoTF-U) (e.g., the key K_(NRC-IoTF-U) 312 in FIG.3). In an aspect of the present disclosure, the encrypted networkreachability context may only be decrypted by the IoTF (e.g., IoTF-C 106and/or IoTF-U 108) to which the client device is attached/associated. Inan aspect of the present disclosure, the network reachability contextmay be compressed prior to encryption.

The encrypted network reachability context may have one or morecharacteristics. For example, an encrypted network reachability contextmay contain the network state information associated with a particularclient device and, therefore, may not be transferrable to other clientdevices. An IoTF-C/U (e.g., the IoTF-C 106 and/or the IoTF-U 108) maynot maintain contexts (e.g., network state information) of a clientdevice. Accordingly, such IoTF-C/U may reconstruct a networkreachability context for a client device by decrypting an encryptednetwork reachability context using its own secret key and, therefore,the IoTF-C/U does not need to store any additional information torecover a network reachability context. The IoTF-C/U may remove anetwork reachability context for a client device under certainconditions (e.g., Evolved Packet System Connection Management (ECM)-Idleor immediately after small data transfer) and restore it when necessary(e.g., for data transfer).

Tracking Area Update Procedure

A client device may perform a tracking area update (TAU) procedure whenthe client device enters into a new tracking area during the idle mode.The TAU message may include the current tracking area ID (TAI) and theGIOTFI or equivalent (e.g., a globally unique mobile management entityidentifier (GUMMEI)) of the source IoTF-C. The target IoTF-C may updatethe location of the client device and the mobility anchor (e.g., IoTF-UID) to one or more network entities (e.g., a P-GW) along with anencrypted network reachability context. In an aspect of the presentdisclosure, the encrypted network reachability context may enable theIoTF-U to verify the downlink packet. In an aspect of the presentdisclosure, an application server (e.g., an IoT server) and/or a P-GWmay transmit a downlink (DL) packet with the encrypted networkreachability context to the IoTF-U/C (identified by the GIOTFI).

FIG. 14 is a signal flow diagram 1400 of a TAU procedure in an IoTnetwork architecture (e.g., IoT network architecture 100) in accordancewith various aspects of the present disclosure. As shown in FIG. 14, thesignal flow diagram 1400 includes a client device 1402 (also referred toas an IoT device), a network access node 1404 (e.g., eNB, base station,network access point), a target IoTF-C 1406 implemented at a targetnetwork device 1405, a source IoTF-C 1408 implemented at a sourcenetwork device 1407, a P-GW 1410, and an IoT server 1412 (also referredto as an application server). The client device 1402 may transmit a datatransfer request message 1414 that includes an encrypted client devicecontext (e.g., a control plane (CP) encrypted client device context) anda TAU request to the network access node 1404. In an aspect of thepresent disclosure, the data transfer request message 1414 may be sentby the client device 1402 without establishing an RRC connection. Thenetwork access node 1404, upon receipt of the data transfer requestmessage 1414, may assign 1416 a temporary identifier (TID) for theclient device 1402 for potential downlink (DL) traffic. The networkaccess node 1404 may further determine the target IoTF-C identifierincluded in the TAU request. The network access node 1404 may thendetermine the IP address of the target IoTF-C 1406, and may transmit amessage 1418 including the TID associated with the client device 1402,the encrypted client device context, and the TAU request to the targetIoTF-C 1406. The target IoTF-C 1406 may transmit a message 1420including a request for the client device context and the encryptedclient device context to the source IoTF-C 1408.

The source IoTF-C 1408 may verify the encrypted client device contextand may transmit a message 1422 including the client device context tothe target IoTF-C 1406. The target IoTF-C 1406 may store 1424 the TIDfor client device and the ID for the network access node 1404, and maygenerate 1424 a new GUTI, a new encrypted network reachability contextfor the client device 1402, and a new encrypted client device contextfor the client device 1402 based on the received client device context.In an aspect, the target IoTF-C 1406 may generate user plane (UP) keysand context generation keys and may provide the keys to an IoTF-U.

The target IoTF-C 1406 may transmit a message 1426 including thetracking area ID (TAI), the ID of the target IoTF-C 1406 (e.g., GIOTFI),and the new encrypted network reachability context to the IoT server1412 (or P-GW 1410). The target IoTF-C 1406 may transmit a message 1428including the TID, the new GUTI, the new encrypted client devicecontext, and the TAU response to the client device 1402. The networkaccess node 1404 may forward the new GUTI, the new client devicecontext, and the TAU response to the client device 1402 in a message1430 based on the TID (e.g., to the client device 1402 identified usingthe TID).

The aspects described herein provide an architecture with new dedicatednetwork functions that enable independent deployment and that avoidscalability/inter-working requirements. The aspects disclosed herein mayenable a network access node (e.g., a base station) to transfer data toor from client devices without storing or maintaining security contextsfor the client devices, thereby avoiding consumption of a substantialamount of resources at network entities (e.g., a network access node orother network entity). Security features may be anchored at a newnetwork function (referred to as the IoT Function (IoTF)). Dedicatedresources are allocated for IoT data transfer in order to avoidaffecting normal client device's PDN connection/traffic. Encryptedclient device contexts and encrypted network reachability contexts maybe used for data transfer to eliminate the client device'ssemi-persistent context at the IoTF when the client device is in theidle state. Consequently, network nodes (e.g., MME/S-GW) do not need tomaintain large amounts of network state information (i.e., contexts) ofclient devices that do not transmit traffic frequently. Client devicesmay employ cost-effective data delivery without exhausting valuable corenetwork resources.

Therefore, the aspects described herein may reduce the aforementionedoverhead for a client device (e.g., a client device operating as an IoTdevice, such as a client device operating in a reduced data transfermode or a low power consumption mode). For example, the client devicemay send traffic to the user plane network function (e.g., IoTF-U)provisioned with the client device security context by the control planenetwork function (e.g., IoTF-C). As such, the network access node (e.g.,eNB, base station, or network access point) may forward the traffic(e.g., packets from the client device) to the next hop node (e.g.,IoTF-U) indicated by the client device without verifying the packet.

The IoTF-C may perform authentication and key agreements with the clientdevice and establish the client device security context for the controlplane. For example, the client device security context may include thecontrol plane key that is used for control plane signaling protection(e.g., encryption and integrity protection). Furthermore, the IoTF-C mayderive the user plane key for user plane packet protection (e.g.,encryption and integrity protection) and may provide the user plane keyto the IoTF-U.

The client device may derive the same control-plane and user-plane keysas the IoTF-C. Therefore, the client device may use control plane keysor user plane keys to send a packet, depending on whether the clientdevice is communicating with the control plane IoTF or user plane IoTFwithout establishing a connection (e.g., client device may makedetermination so different security keys or context may be applied).

First Exemplary Apparatus (e.g., Client Device) and Method Thereon

FIG. 15 is an illustration of an apparatus 1500 configured tocommunicate with a network based on an IoT network architectureaccording to one or more aspects of the disclosure (e.g., aspectsrelated to the method of FIG. 16 described below). In an aspect, theapparatus 1500 may be a client device (e.g., an IoT device). Theapparatus 1500 includes a communication interface (e.g., at least onetransceiver) 1502, a storage medium 1504, a user interface 1506, amemory device 1508, and a processing circuit 1510.

These components can be coupled to and/or placed in electricalcommunication with one another via a signaling bus or other suitablecomponent, represented generally by the connection lines in FIG. 15. Thesignaling bus may include any number of interconnecting buses andbridges depending on the specific application of the processing circuit1510 and the overall design constraints. The signaling bus linkstogether various circuits such that each of the communication interface1502, the storage medium 1504, the user interface 1506, and the memorydevice 1508 are coupled to and/or in electrical communication with theprocessing circuit 1510. The signaling bus may also link various othercircuits (not shown) such as timing sources, peripherals, voltageregulators, and power management circuits, which are well known in theart, and therefore, will not be described any further.

The communication interface 1502 may be adapted to facilitate wirelesscommunication of the apparatus 1500. For example, the communicationinterface 1502 may include circuitry and/or code (e.g., instructions)adapted to facilitate the communication of information bi-directionallywith respect to one or more communication devices in a network. Thecommunication interface 1502 may be coupled to one or more antennas 1512for wireless communication within a wireless communication system. Thecommunication interface 1502 can be configured with one or morestandalone receivers and/or transmitters, as well as one or moretransceivers. In the illustrated example, the communication interface1502 includes a transmitter 1514 and a receiver 1516.

The memory device 1508 may represent one or more memory devices. Asindicated, the memory device 1508 may maintain network-relatedinformation/along with other information used by the apparatus 1500. Insome implementations, the memory device 1508 and the storage medium 1504are implemented as a common memory component. The memory device 1508 mayalso be used for storing data that is manipulated by the processingcircuit 1510 or some other component of the apparatus 1500.

The storage medium 1504 may represent one or more computer-readable,machine-readable, and/or processor-readable devices for storing code,such as processor executable code or instructions (e.g., software,firmware), electronic data, databases, or other digital information. Thestorage medium 1504 may also be used for storing data that ismanipulated by the processing circuit 1510 when executing code. Thestorage medium 1504 may be any available media that can be accessed by ageneral purpose or special purpose processor, including portable orfixed storage devices, optical storage devices, and various othermediums capable of storing, containing or carrying code.

By way of example and not limitation, the storage medium 1504 mayinclude a magnetic storage device (e.g., hard disk, floppy disk,magnetic strip), an optical disk (e.g., a compact disc (CD) or a digitalversatile disc (DVD)), a smart card, a flash memory device (e.g., acard, a stick, or a key drive), a random access memory (RAM), a readonly memory (ROM), a programmable ROM (PROM), an erasable PROM (EPROM),an electrically erasable PROM (EEPROM), a register, a removable disk,and any other suitable medium for storing code that may be accessed andread by a computer. The storage medium 1504 may be embodied in anarticle of manufacture (e.g., a computer program product). By way ofexample, a computer program product may include a computer-readablemedium in packaging materials. In view of the above, in someimplementations, the storage medium 1504 may be a non-transitory (e.g.,tangible) storage medium.

The storage medium 1504 may be coupled to the processing circuit 1510such that the processing circuit 1510 can read information from, andwrite information to, the storage medium 1504. That is, the storagemedium 1504 can be coupled to the processing circuit 1510 so that thestorage medium 1504 is at least accessible by the processing circuit1510, including examples where at least one storage medium is integralto the processing circuit 1510 and/or examples where at least onestorage medium is separate from the processing circuit 1510 (e.g.,resident in the apparatus 1500, external to the apparatus 1500,distributed across multiple entities, etc.).

Code and/or instructions stored by the storage medium 1504, whenexecuted by the processing circuit 1510, causes the processing circuit1510 to perform one or more of the various functions and/or processoperations described herein. For example, the storage medium 1504 mayinclude operations configured for regulating operations at one or morehardware blocks of the processing circuit 1510, as well as to utilizethe communication interface 1502 for wireless communication utilizingtheir respective communication protocols.

The processing circuit 1510 is generally adapted for processing,including the execution of such code/instructions stored on the storagemedium 1504. As used herein, the term “code” or “instructions” shall beconstrued broadly to include without limitation programming,instructions, instruction sets, data, code, code segments, program code,programs, subprograms, software modules, applications, softwareapplications, software packages, routines, subroutines, objects,executables, threads of execution, procedures, functions, etc., whetherreferred to as software, firmware, middleware, microcode, hardwaredescription language, or otherwise.

The processing circuit 1510 is arranged to obtain, process and/or senddata, control data access and storage, issue commands, and control otherdesired operations. The processing circuit 1510 may include circuitryconfigured to implement desired code provided by appropriate media in atleast one example. For example, the processing circuit 1510 may beimplemented as one or more processors, one or more controllers, and/orother structure configured to execute executable code. Examples of theprocessing circuit 1510 may include a general purpose processor, adigital signal processor (DSP), an application specific integratedcircuit (ASIC), a field programmable gate array (FPGA) or otherprogrammable logic component, discrete gate or transistor logic,discrete hardware components, or any combination thereof designed toperform the functions described herein. A general purpose processor mayinclude a microprocessor, as well as any conventional processor,controller, microcontroller, or state machine. The processing circuit1510 may also be implemented as a combination of computing components,such as a combination of a DSP and a microprocessor, a number ofmicroprocessors, one or more microprocessors in conjunction with a DSPcore, an ASIC and a microprocessor, or any other number of varyingconfigurations. These examples of the processing circuit 1510 are forillustration and other suitable configurations within the scope of thedisclosure are also contemplated.

According to one or more aspects of the disclosure, the processingcircuit 1510 may be adapted to perform any or all of the features,processes, functions, operations and/or routines for any or all of theapparatuses described herein. As used herein, the term “adapted” inrelation to the processing circuit 1510 may refer to the processingcircuit 1510 being one or more of configured, employed, implemented,and/or programmed to perform a particular process, function, operationand/or routine according to various features described herein.

According to at least one example of the apparatus 1500, the processingcircuit 1510 may include one or more of a transmitting circuit/module1520, a receiving circuit/module 1522, a security context obtainingcircuit/module 1524, a key obtaining circuit/module 1526, a data packetprotecting circuit/module 1528, a packet determining circuit/module1530, a packet decoding circuit/module 1532, and/or a networkregistering circuit/module 1534 that are adapted to perform any or allof the features, processes, functions, operations and/or routinesdescribed herein (e.g., features, processes, functions, operationsand/or routines described with respect to FIG. 16).

The transmitting circuit/module 1520 may include circuitry and/orinstructions (e.g., transmitting instructions 1540 stored on the storagemedium 1504) adapted to perform several functions relating to, forexample, transmitting a request to attach to the network and/ortransmitting a data packet or the control packet. For example, in oneaspect, the data packet may be a data packet that has been protectedwith a user plane key and the control packet may be a control packetthat has been protected with a control plane key.

The receiving circuit/module 1522 may include circuitry and/orinstructions (e.g., receiving instructions 1542 stored on the storagemedium 1504) adapted to perform several functions relating to, forexample, receiving, from the network, a message associated with anauthentication procedure, and receiving a packet from the network.

The security context obtaining circuit/module 1524 may include circuitryand/or instructions (e.g., security context obtaining instructions 1544stored on the storage medium 1504) adapted to perform several functionsrelating to, for example, obtaining at least one of a user planesecurity context indicating network state information for the clientdevice with respect to a user plane, or a control plane security contextindicating network state information for the client device with respectto a control plane.

The key obtaining circuit/module 1526 may include circuitry and/orinstructions (e.g., key obtaining instructions 1546 stored on thestorage medium 1504) adapted to perform several functions relating to,for example, obtaining at least a user plane key shared with a userplane network function implemented at a first network node or a controlplane key shared with a control plane network function implemented at asecond network node.

The data packet protecting circuit/module 1528 may include circuitryand/or instructions (e.g., data packet protecting instructions 1548stored on the storage medium 1504) adapted to perform several functionsrelating to, for example, protecting a data packet with the user planekey or a control packet with the control plane key. In an aspect, thedata packet includes first destination information indicating that thedata packet is to be processed at the first network node, the firstdestination information enabling a network access node to forward thedata packet to the first network node. In an aspect, the control packetincludes second destination information indicating that the controlpacket is to be processed at the second network node, the seconddestination information enabling the network access node to forward thecontrol packet to the second network node.

The packet determining circuit/module 1530 may include circuitry and/orinstructions (e.g., packet determining instructions 1550 stored on thestorage medium 1504) adapted to perform several functions relating to,for example, determining whether the received packet includes data orcontrol information.

The packet decoding circuit/module 1532 may include circuitry and/orinstructions (e.g., packet decoding instructions 1552 stored on thestorage medium 1504) adapted to perform several functions relating to,for example, decoding the received packet with the user plane key or thecontrol plane key.

The network registering circuit/module 1534 may include circuitry and/orinstructions (e.g., network registering instructions 1554 stored on thestorage medium 1504) adapted to perform several functions relating to,for example, registering to a network as an Internet of Things device

As mentioned above, instructions stored by the storage medium 1504, whenexecuted by the processing circuit 1510, causes the processing circuit1510 to perform one or more of the various functions and/or processoperations described herein. For example, the storage medium 1504 mayinclude one or more of the transmitting instructions 1540, a receivinginstructions 1542, security context obtaining instructions 1544, keyobtaining instructions 1546, data packet protecting instructions 1548,packet determining instructions 1550, packet decoding instructions 1552,and/or network registering instructions 1554.

FIG. 16 is a flowchart 1600 illustrating a method for communicating witha network in accordance with various aspects of the disclosure. Themethod may be performed by an apparatus such as a client device (e.g.,the client device 102, 502, 702, or the apparatus 1500). It should beunderstood that the operations indicated by dashed lines in FIG. 16represent optional operations.

The client device registers to the network 1602. In an aspect, theclient device may register to the network by transmitting a request toattach to the network and by receiving, from the network, a messageassociated with an authentication procedure in response to the request.In an aspect, the attach request may provide one or more indicationssuch as, for example, that the client device is to attach as an Internetof Things device, that the client device is to attach in a reduced datatransfer mode, and/or that the client device is to attach in a low powerconsumption mode.

The client device obtains at least one of a user plane security contextindicating network state information for the client device with respectto a user plane, or a control plane security context indicating networkstate information for the client device with respect to a control plane1604. In one example, the client device may obtain the user planesecurity context by deriving a first encryption key and a firstintegrity key based on the user plane key. In another example, theclient device may obtain the control plane security context by derivinga second encryption key and a second integrity key based on the controlplane key. In an aspect, the user plane security context or the controlplane security context does not include access stratum securityprotection.

The client device obtains at least a user plane key shared with a userplane network function implemented at a first network node or a controlplane key shared with a control plane network function implemented at asecond network node 1606. For example, the client device may obtain theuser plane key or the control plane key based on the message associatedwith the authentication procedure.

The client device protects a data packet with the user plane key or acontrol packet with the control plane key 1608. In one example, the datapacket may be encrypted or integrity protected, or both encrypted andintegrity protected, based on the user plane key. In another example,the control packet is encrypted or integrity protected, or bothencrypted and integrity protected, based on the control plane key.

In an aspect, the data packet includes first destination informationindicating that the data packet is to be processed at the first networknode, the first destination information enabling a network access nodeto forward the data packet to the first network node. In an aspect, thecontrol packet includes second destination information indicating thatthe control packet is to be processed at the second network node, thesecond destination information enabling the network access node toforward the control packet to the second network node.

The apparatus transmits the data packet or the control packet 1610. Theapparatus receives a packet from the network 1612. In an aspect, a userplane Internet of Things Function identifier (IID) or a control planeInternet of Things Function identifier (IID) is included in a header ofthe received packet under one or more conditions. The one or moreconditions may include, for example, when the client device isregistered to the network as an Internet of Things device, when theclient device operates in a low power consumption mode, or when theclient device is configured to transfer a reduced amount of data.

The client device determines whether the received packet includes dataor control information 1614. The client device decodes the receivedpacket with the user plane key or the control plane key based on thedetermination 1616. In an aspect, the client device decodes the receivedpacket by decrypting and verifying the received packet with the userplane key or the control plane key. In an aspect, the client deviceverifies the received packet by determining a first messageauthentication code (MAC) and comparing the first MAC to a second MACassociated with the received packet. For example, the first MAC may bedetermined by applying a message authentication code generationalgorithm based on the received packet and using either the user planekey or the control plane key.

Second Exemplary Apparatus (e.g., Network Access Node) and MethodThereon

FIG. 17 is an illustration of an apparatus 1700 configured tocommunicate with a network based on an IoT network architectureaccording to one or more aspects of the disclosure (e.g., aspectsrelated to the method of FIG. 18 described below). In an aspect, theapparatus 1700 may be a network access node (e.g., eNB, base station, ornetwork access point). The apparatus 1700 includes a communicationinterface (e.g., at least one transceiver) 1702, a network communicationinterface 1703, a storage medium 1704, a user interface 1706, a memorydevice 1708, and a processing circuit 1710.

These components can be coupled to and/or placed in electricalcommunication with one another via a signaling bus or other suitablecomponent, represented generally by the connection lines in FIG. 17. Thesignaling bus may include any number of interconnecting buses andbridges depending on the specific application of the processing circuit1710 and the overall design constraints. The signaling bus linkstogether various circuits such that each of the communication interface1702, network communication interface 1703, the storage medium 1704, theuser interface 1706, and the memory device 1708 are coupled to and/or inelectrical communication with the processing circuit 1710. The signalingbus may also link various other circuits (not shown) such as timingsources, peripherals, voltage regulators, and power management circuits,which are well known in the art, and therefore, will not be describedany further.

The communication interface 1702 may be adapted to facilitate wirelesscommunication of the apparatus 1700. For example, the communicationinterface 1702 may include circuitry and/or code (e.g., instructions)adapted to facilitate the communication of information bi-directionallywith respect to one or more client devices in a network. Thecommunication interface 1702 may be coupled to one or more antennas 1712for wireless communication within a wireless communication system. Thecommunication interface 1702 can be configured with one or morestandalone receivers and/or transmitters, as well as one or moretransceivers. In the illustrated example, the communication interface1702 includes a transmitter 1714 and a receiver 1716.

The network communication interface 1703 may be adapted to facilitatecommunication of the apparatus 1700. For example, the networkcommunication interface 1703 may include circuitry and/or code (e.g.,instructions) adapted to facilitate the communication of informationbi-directionally with respect to one or more network entities in anetwork. The network communication interface 1703 can be configured withone or more standalone receivers and/or transmitters, as well as one ormore transceivers.

The memory device 1708 may represent one or more memory devices. Asindicated, the memory device 1708 may maintain network-relatedinformation/along with other information used by the apparatus 1700. Insome implementations, the memory device 1708 and the storage medium 1704are implemented as a common memory component. The memory device 1708 mayalso be used for storing data that is manipulated by the processingcircuit 1710 or some other component of the apparatus 1700.

The storage medium 1704 may represent one or more computer-readable,machine-readable, and/or processor-readable devices for storing code,such as processor executable code or instructions (e.g., software,firmware), electronic data, databases, or other digital information. Thestorage medium 1704 may also be used for storing data that ismanipulated by the processing circuit 1710 when executing code. Thestorage medium 1704 may be any available media that can be accessed by ageneral purpose or special purpose processor, including portable orfixed storage devices, optical storage devices, and various othermediums capable of storing, containing or carrying code.

By way of example and not limitation, the storage medium 1704 mayinclude a magnetic storage device (e.g., hard disk, floppy disk,magnetic strip), an optical disk (e.g., a compact disc (CD) or a digitalversatile disc (DVD)), a smart card, a flash memory device (e.g., acard, a stick, or a key drive), a random access memory (RAM), a readonly memory (ROM), a programmable ROM (PROM), an erasable PROM (EPROM),an electrically erasable PROM (EEPROM), a register, a removable disk,and any other suitable medium for storing code that may be accessed andread by a computer. The storage medium 1704 may be embodied in anarticle of manufacture (e.g., a computer program product). By way ofexample, a computer program product may include a computer-readablemedium in packaging materials. In view of the above, in someimplementations, the storage medium 1704 may be a non-transitory (e.g.,tangible) storage medium.

The storage medium 1704 may be coupled to the processing circuit 1710such that the processing circuit 1710 can read information from, andwrite information to, the storage medium 1704. That is, the storagemedium 1704 can be coupled to the processing circuit 1710 so that thestorage medium 1704 is at least accessible by the processing circuit1710, including examples where at least one storage medium is integralto the processing circuit 1710 and/or examples where at least onestorage medium is separate from the processing circuit 1710 (e.g.,resident in the apparatus 1700, external to the apparatus 1700,distributed across multiple entities, etc.).

Code and/or instructions stored by the storage medium 1704, whenexecuted by the processing circuit 1710, causes the processing circuit1710 to perform one or more of the various functions and/or processoperations described herein. For example, the storage medium 1704 mayinclude operations configured for regulating operations at one or morehardware blocks of the processing circuit 1710, as well as to utilizethe communication interface 1702 for wireless communication and thenetwork communication interface 1703 for network communication utilizingtheir respective communication protocols.

The processing circuit 1710 is generally adapted for processing,including the execution of such code/instructions stored on the storagemedium 1704. As used herein, the term “code” or “instructions” shall beconstrued broadly to include without limitation programming,instructions, instruction sets, data, code, code segments, program code,programs, subprograms, software modules, applications, softwareapplications, software packages, routines, subroutines, objects,executables, threads of execution, procedures, functions, etc., whetherreferred to as software, firmware, middleware, microcode, hardwaredescription language, or otherwise.

The processing circuit 1710 is arranged to obtain, process and/or senddata, control data access and storage, issue commands, and control otherdesired operations. The processing circuit 1710 may include circuitryconfigured to implement desired code provided by appropriate media in atleast one example. For example, the processing circuit 1710 may beimplemented as one or more processors, one or more controllers, and/orother structure configured to execute executable code. Examples of theprocessing circuit 1710 may include a general purpose processor, adigital signal processor (DSP), an application specific integratedcircuit (ASIC), a field programmable gate array (FPGA) or otherprogrammable logic component, discrete gate or transistor logic,discrete hardware components, or any combination thereof designed toperform the functions described herein. A general purpose processor mayinclude a microprocessor, as well as any conventional processor,controller, microcontroller, or state machine. The processing circuit1710 may also be implemented as a combination of computing components,such as a combination of a DSP and a microprocessor, a number ofmicroprocessors, one or more microprocessors in conjunction with a DSPcore, an ASIC and a microprocessor, or any other number of varyingconfigurations. These examples of the processing circuit 1710 are forillustration and other suitable configurations within the scope of thedisclosure are also contemplated.

According to one or more aspects of the disclosure, the processingcircuit 1710 may be adapted to perform any or all of the features,processes, functions, operations and/or routines for any or all of theapparatuses described herein. As used herein, the term “adapted” inrelation to the processing circuit 1710 may refer to the processingcircuit 1710 being one or more of configured, employed, implemented,and/or programmed to perform a particular process, function, operationand/or routine according to various features described herein.

According to at least one example of the apparatus 1700, the processingcircuit 1710 may include one or more of a receiving circuit/module 1720,a data packet forwarding circuit/module 1722, a temporary identifieradding circuit/module 1724, a storing circuit/module 1726, a next hopdetermining circuit/module 1728, a client device identifyingcircuit/module 1730, and a temporary identifier removing circuit/module1732 that are adapted to perform any or all of the features, processes,functions, operations and/or routines described herein (e.g., features,processes, functions, operations and/or routines described with respectto FIG. 18).

The receiving circuit/module 1720 may include circuitry and/orinstructions (e.g., the receiving instructions 1740 stored on thestorage medium 1704) adapted to perform several functions relating to,for example, receiving, from the client device, a request to attach to anetwork with an indication of the network attach mode, where the networkattach mode is a reduced data transfer mode or a low power consumptionmode, receiving a first packet from a client device, and receiving asecond packet from a network node.

The packet forwarding circuit/module 1722 may include circuitry and/orinstructions (e.g., the packet forwarding instructions 1742 stored onthe storage medium 1704) adapted to perform several functions relatingto, for example, forwarding the first packet to the next hop networknode, and forwarding the second packet received from the network node tothe client device.

The temporary identifier adding circuit/module 1724 may includecircuitry and/or instructions (e.g., the temporary identifier addinginstructions 1744 stored on the storage medium 1704) adapted to performseveral functions relating to, for example, adding, to the first packet,a temporary identifier associated with the client device. In an aspect,the first packet is a data packet or a control packet. In an aspect, thetemporary identifier is a cell radio network temporary identifier(C-RNTI).

The storing circuit/module 1726 may include circuitry and/orinstructions (e.g., the storing instructions 1746 stored on the storagemedium 1704) adapted to perform several functions relating to, forexample, storing the temporary identifier. In an aspect, the temporaryidentifier is stored for a predetermined period of time.

The next hop determining circuit/module 1728 may include circuitryand/or instructions (e.g., the next hop determining instructions 1748stored on the storage medium 1704) adapted to perform several functionsrelating to, for example, determining a next hop network node based on anetwork attach mode of the client device. In an aspect, thedetermination of the next hop network node is based on preconfiguredinformation at the network access node or based on destinationinformation included in the first packet when the network attach mode ofthe client device is the reduced data transfer mode or the low powerconsumption mode. In an aspect, the destination information includes anetwork function identifier that enables identification of a networknode or network device implementing a network function. In an aspect,the network function identifier is associated with a control planenetwork function implemented at a first network node or a user planenetwork function implemented at a second network node.

The client device identifying circuit/module 1730 may include circuitryand/or instructions (e.g., client device identifying instructions 1750stored on the storage medium 1704) adapted to perform several functionsrelating to, for example, identifying the client device from a temporaryidentifier in the second packet. In an aspect, the second packet is adata packet or a control packet

The temporary identifier removing circuit/module 1732 may includecircuitry and/or instructions (e.g., the temporary identifier removinginstructions 1752 stored on the storage medium 1704) adapted to performseveral functions relating to, for example, removing the temporaryidentifier from the second packet prior to forwarding the second packet.

As mentioned above, instructions stored by the storage medium 1704, whenexecuted by the processing circuit 1710, causes the processing circuit1710 to perform one or more of the various functions and/or processoperations described herein. For example, the storage medium 1704 mayinclude one or more of the receiving instructions 1740, the packetforwarding instructions 1742, the temporary identifier addinginstructions 1744, the storing instructions 1746, the next hopdetermining instructions 1748, the client device identifyinginstructions 1750, and the temporary identifier removing instructions1752.

FIG. 18 (including FIGS. 18A and 18B) is a flowchart 1800 illustrating amethod for communicating in an IoT network architecture in accordancewith various aspects of the present disclosure. The method may beperformed by an apparatus such as a network access node (e.g., thenetwork access node 104 of FIG. 1 or apparatus 1700 of FIG. 17). Itshould be understood that the operations indicated by dashed lines inFIG. 18 represent optional operations.

With reference to FIG. 18A, the network access node receives, from theclient device, a request to attach to a network with an indication ofthe network attach mode, where the network attach mode is a reduced datatransfer mode 1802. In other aspects, the network attach mode may be anInternet of Things (IoT) device mode or a low power consumption mode.The network access node receives a first packet from the client device1804. For example, the first packet may be a data packet or a controlpacket.

The first network node adds, to the first packet, a temporary identifierassociated with the client device 1806. In an aspect of the presentdisclosure, the temporary identifier is a cell radio network temporaryidentifier (C-RNTI). The network access node stores the temporaryidentifier 1808. In an aspect of the present disclosure, the temporaryidentifier is stored for a predetermined period of time.

The network access node determines a next hop network node based on anetwork attach mode of the client device 1810. In an aspect of thepresent disclosure, the determination of the next hop network node ispreconfigured at the network access node. In an aspect of the presentdisclosure, the next hop network node may be determined based ondestination information included in the first packet when the networkattach mode of the client device is the IoT device mode, the reduceddata transfer mode, or the low power consumption mode. For example, thedestination information may include a network function identifier thatenables identification of a network node implementing a networkfunction. In an aspect, the network function identifier is associatedwith a control plane network function implemented at a first networknode or a user plane network function implemented at a second networknode.

The network access node forwards the first packet to the next hopnetwork node without verifying the first packet received from the clientdevice when the network attach mode is a reduced data transfer mode1812.

With reference to FIG. 18B, the network access node receives a secondpacket from a network node 1814. For example, the second packet may be adata packet or a control packet. The network access node identifies theclient device from a temporary identifier in the second packet 1816. Thenetwork access node removes the temporary identifier from the secondpacket prior to forwarding the second packet 1818. The network accessnode forwards the second packet received from the network node to theclient device without protecting the second packet when the networkattach mode of the client device is the reduced data transfer mode 1820.

Third Exemplary Apparatus (e.g., Network Device) and Method Thereon

FIG. 19 is an illustration of an apparatus 1900 according to one or moreaspects of the disclosure (e.g., aspects related to the method of FIGS.20-22 described below). In an aspect, the apparatus 1900 may be anetwork device (e.g., network device 105, 505) that implements anInternet of Things (IoT) Function. For example, the IoT Function mayinclude a control plane IoT Function (e.g., IoTF-C 106, 506, 706, 606,906, 1406) and/or a user plane IoT Function (e.g., IoTF-U 108, 508, 608,708, 806, 908) as previously discussed. In some aspects, the apparatus1900 may be a network node that implements an IoT Function, such as thenetwork node 107 that implements the IoTF-C 106 in FIG. 1 or the networknode 109 that implements the IoTF-U 108 in FIG. 1. The apparatus 1900includes a network communication interface (e.g., at least onetransceiver) 1902, a storage medium 1904, a user interface 1906, amemory device 1908, and a processing circuit 1910.

These components can be coupled to and/or placed in electricalcommunication with one another via a signaling bus or other suitablecomponent, represented generally by the connection lines in FIG. 19. Thesignaling bus may include any number of interconnecting buses andbridges depending on the specific application of the processing circuit1910 and the overall design constraints. The signaling bus linkstogether various circuits such that each of the network communicationinterface 1902, the storage medium 1904, the user interface 1906, andthe memory device 1908 are coupled to and/or in electrical communicationwith the processing circuit 1910. The signaling bus may also linkvarious other circuits (not shown) such as timing sources, peripherals,voltage regulators, and power management circuits, which are well knownin the art, and therefore, will not be described any further.

The network communication interface 1902 may be adapted to facilitatecommunication of the apparatus 1900. For example, the networkcommunication interface 1902 may include circuitry and/or code (e.g.,instructions) adapted to facilitate the communication of informationbi-directionally with respect to one or more network entities in anetwork. The network communication interface 1902 can be configured withone or more standalone receivers and/or transmitters, as well as one ormore transceivers.

The memory device 1908 may represent one or more memory devices. Asindicated, the memory device 1908 may maintain network-relatedinformation along with other information used by the apparatus 1900. Insome implementations, the memory device 1908 and the storage medium 1904are implemented as a common memory component. The memory device 1908 mayalso be used for storing data that is manipulated by the processingcircuit 1910 or some other component of the apparatus 1900.

The storage medium 1904 may represent one or more computer-readable,machine-readable, and/or processor-readable devices for storing code,such as processor executable code or instructions (e.g., software,firmware), electronic data, databases, or other digital information. Thestorage medium 1904 may also be used for storing data that ismanipulated by the processing circuit 1910 when executing code. Thestorage medium 1904 may be any available media that can be accessed by ageneral purpose or special purpose processor, including portable orfixed storage devices, optical storage devices, and various othermediums capable of storing, containing or carrying code.

By way of example and not limitation, the storage medium 1904 mayinclude a magnetic storage device (e.g., hard disk, floppy disk,magnetic strip), an optical disk (e.g., a compact disc (CD) or a digitalversatile disc (DVD)), a smart card, a flash memory device (e.g., acard, a stick, or a key drive), a random access memory (RAM), a readonly memory (ROM), a programmable ROM (PROM), an erasable PROM (EPROM),an electrically erasable PROM (EEPROM), a register, a removable disk,and any other suitable medium for storing code that may be accessed andread by a computer. The storage medium 1904 may be embodied in anarticle of manufacture (e.g., a computer program product). By way ofexample, a computer program product may include a computer-readablemedium in packaging materials. In view of the above, in someimplementations, the storage medium 1904 may be a non-transitory (e.g.,tangible) storage medium.

The storage medium 1904 may be coupled to the processing circuit 1910such that the processing circuit 1910 can read information from, andwrite information to, the storage medium 1904. That is, the storagemedium 1904 can be coupled to the processing circuit 1910 so that thestorage medium 1904 is at least accessible by the processing circuit1910, including examples where at least one storage medium is integralto the processing circuit 1910 and/or examples where at least onestorage medium is separate from the processing circuit 1910 (e.g.,resident in the apparatus 1900, external to the apparatus 1900,distributed across multiple entities, etc.).

Code and/or instructions stored by the storage medium 1904, whenexecuted by the processing circuit 1910, causes the processing circuit1910 to perform one or more of the various functions and/or processoperations described herein. For example, the storage medium 1904 mayinclude operations configured for regulating operations at one or morehardware blocks of the processing circuit 1910, as well as to utilizethe network communication interface 1902 for communication utilizingtheir respective communication protocols.

The processing circuit 1910 is generally adapted for processing,including the execution of such code/instructions stored on the storagemedium 1904. As used herein, the term “code” or “instructions” shall beconstrued broadly to include without limitation programming,instructions, instruction sets, data, code, code segments, program code,programs, subprograms, software modules, applications, softwareapplications, software packages, routines, subroutines, objects,executables, threads of execution, procedures, functions, etc., whetherreferred to as software, firmware, middleware, microcode, hardwaredescription language, or otherwise.

The processing circuit 1910 is arranged to obtain, process and/or senddata, control data access and storage, issue commands, and control otherdesired operations. The processing circuit 1910 may include circuitryconfigured to implement desired code provided by appropriate media in atleast one example. For example, the processing circuit 1910 may beimplemented as one or more processors, one or more controllers, and/orother structure configured to execute executable code. Examples of theprocessing circuit 1910 may include a general purpose processor, adigital signal processor (DSP), an application specific integratedcircuit (ASIC), a field programmable gate array (FPGA) or otherprogrammable logic component, discrete gate or transistor logic,discrete hardware components, or any combination thereof designed toperform the functions described herein. A general purpose processor mayinclude a microprocessor, as well as any conventional processor,controller, microcontroller, or state machine. The processing circuit1910 may also be implemented as a combination of computing components,such as a combination of a DSP and a microprocessor, a number ofmicroprocessors, one or more microprocessors in conjunction with a DSPcore, an ASIC and a microprocessor, or any other number of varyingconfigurations. These examples of the processing circuit 1910 are forillustration and other suitable configurations within the scope of thedisclosure are also contemplated.

According to one or more aspects of the disclosure, the processingcircuit 1910 may be adapted to perform any or all of the features,processes, functions, operations and/or routines for any or all of theapparatuses described herein. As used herein, the term “adapted” inrelation to the processing circuit 1910 may refer to the processingcircuit 1910 being one or more of configured, employed, implemented,and/or programmed to perform a particular process, function, operationand/or routine according to various features described herein.

According to at least one example of the apparatus 1900, the processingcircuit 1910 may include one or more of a security context establishingcircuit/module 1920, a control plane key and user plane key obtainingcircuit/module 1922, a key transferring circuit/module 1924, a securitycontext obtaining circuit/module 1926, a user plane key determiningcircuit/module 1928, a packet receiving circuit/module 1930, a packetdecrypting and authenticating circuit/module 1932, a packet protectingcircuit/module 1934, and a packet transmitting circuit/module 1936 thatare adapted to perform any or all of the features, processes, functions,operations and/or routines described herein (e.g., features, processes,functions, operations and/or routines described with respect to FIGS.20-22).

The security context establishing circuit/module 1920 may includecircuitry and/or instructions (e.g., the security context establishinginstructions 1940 stored on the storage medium 1904) adapted to performseveral functions relating to, for example, establishing, at a controlplane network function implemented at a first network node, a securitycontext for a client device.

The control plane key and user plane key obtaining circuit/module 1922may include circuitry and/or instructions (e.g., the control plane keyand user plane key generating obtaining 1942 stored on the storagemedium 1904) adapted to perform several functions relating to, forexample, obtaining, at the control plane network function implemented atthe first network node, a control plane key for the control planenetwork function, and/or obtaining, at the control plane networkfunction implemented at the first network node, a user plane key for auser plane network function implemented at a second network node.

The key transferring circuit/module 1924 may include circuitry and/orinstructions (e.g., the key transferring instructions 1944 stored on thestorage medium 1904) adapted to perform several functions relating to,for example, transferring, from the control plane network functionimplemented at the first network node, the user plane key to the userplane network function implemented at a second network node.

The security context obtaining circuit/module 1926 may include circuitryand/or instructions (e.g., the security context obtaining instructions1946 stored on the storage medium 1904) adapted to perform severalfunctions relating to, for example, obtaining, at a user plane networkfunction implemented at the network node, a security context for aclient device.

The user plane key determining circuit/module 1928 may include circuitryand/or instructions (e.g., the user plane key determining instructions1948 stored on the storage medium 1904) adapted to perform severalfunctions relating to, for example, determining, at the user planenetwork function implemented at the network node, a key to be used atleast for decryption or verification of a data packet from the clientdevice and/or determining, at the user plane network functionimplemented at the network node, at least one key associated with theclient device.

The packet receiving circuit/module 1930 may include circuitry and/orinstructions (e.g., the packet receiving instructions 1950 stored on thestorage medium 1904) adapted to perform several functions relating to,for example, receiving, at the user plane network function implementedat the network node, a data packet from the client device and/orreceiving, at the user plane network function implemented at the networknode, a data packet for the client device from an application server orgateway.

The packet decrypting and authenticating circuit/module 1932 may includecircuitry and/or instructions (e.g., the packet decrypting andauthenticating instructions 1952 stored on the storage medium 1904)adapted to perform several functions relating to, for example,decrypting and verifying, at the user plane network function implementedat the network node, the data packet from the client device based on thekey.

The packet protecting circuit/module 1934 may include circuitry and/orinstructions (e.g., the packet protecting instructions 1954 stored onthe storage medium 1904) adapted to perform several functions relatingto, for example, protecting, at the user plane network functionimplemented at the network node, the data packet for the client deviceusing the at least one key.

The packet transmitting circuit/module 1936 may include circuitry and/orinstructions (e.g., the packet transmitting instructions 1956 stored onthe storage medium 1904) adapted to perform several functions relatingto, for example, transmitting, from the user plane network functionimplemented at the network node, the data packet for the client deviceto the next hop network node.

As mentioned above, instructions stored by the storage medium 1904, whenexecuted by the processing circuit 1910, causes the processing circuit1910 to perform one or more of the various functions and/or processoperations described herein. For example, the storage medium 1904 mayinclude one or more of the security context establishing instructions1940, control plane key and user plane key obtaining instructions 1942,key transferring instructions 1944, security context obtaininginstructions 1946, user plane key determining instructions 1948, packetreceiving instructions 1950, packet decrypting and authenticatinginstructions 1952, packet protecting instructions 1954, and packettransmitting instructions 1956.

FIG. 20 is a flowchart 2000 illustrating a method for communicating inan IoT network architecture in accordance with various aspects of thedisclosure. The method may be performed by an apparatus such as a firstnetwork node. For example, the first network node (e.g., the networknode 707) may implement a control plane network function (e.g., theIoTF-C 706). The first network node establishes, at a control planenetwork function implemented at the network node, a security context fora client device 2002. In an aspect, the first network node establishesthe security context for the client device by performing a mutualauthentication procedure with the client device.

The first network node obtains, at the control plane network functionimplemented at the first network node, a control plane key for thecontrol plane network function 2004. The first network node obtains, atthe control plane network function implemented at the first networknode, a user plane key for a user plane network function implemented ata second network node 2006. In an aspect, the first network node obtainsthe user plane key by deriving the user plane key from a sessioncredential established during the mutual authentication procedure. Thefirst network node transfers, from the control plane network functionimplemented at the first network node, the user plane key to the userplane network function implemented at the second network node 2008.

FIG. 21 is a flowchart 2100 illustrating a method for communicating inan IoT network architecture in accordance with various aspects of thedisclosure. The method may be performed by an apparatus such as anetwork node. For example, the network node (e.g., the network node 707)may implement a user plane network function (e.g., the IoTF-U 708). Thenetwork node obtains, at a user plane network function implemented atthe network node, a security context for a client device 2102. In anaspect, the network node obtains the security context by receiving thesecurity context from a control plane network function of the networknode. The network node determines, at the user plane network functionimplemented at the network node, a key to be used at least fordecryption or verification of a data packet from the client device 2104.The network node receives, at the user plane network function of thenetwork node, the data packet from the client device 2106. The networknode decrypts and verifies, at the user plane network functionimplemented at the network node, the data packet from the client devicebased on the key 2108.

FIG. 22 is a flowchart 2200 illustrating a method for communicating inan IoT network architecture in accordance with various aspects of thedisclosure. The method may be performed by an apparatus such as anetwork node. For example, the network node (e.g., the network node 707)may implement a user plane network function (e.g., the IoTF-U 708).

The network node obtains, at a user plane network function implementedat the network node, a security context for a client device 2202. Thenetwork node receives, at the user plane network function implemented atthe network node, a data packet for the client device from anapplication server or gateway 2204. The network node determines, at theuser plane network function implemented at the network node, at leastone key associated with the client device 2206. The network nodeprotects, at the user plane network function implemented at the networknode, the data packet for the client device using the at least one key2208. The network node transmits, from the user plane network functionimplemented at the network node, the data packet for the client deviceto the next hop network node 2210.

One or more of the components, steps, features and/or functionsillustrated in the figures may be rearranged and/or combined into asingle component, step, feature or function or embodied in severalcomponents, steps, or functions. Additional elements, components, steps,and/or functions may also be added without departing from novel featuresdisclosed herein. The apparatus, devices, and/or components illustratedin the figures may be configured to perform one or more of the methods,features, or steps described herein. The novel algorithms describedherein may also be efficiently implemented in software and/or embeddedin hardware.

It is to be understood that the specific order or hierarchy of steps inthe methods disclosed is an illustration of exemplary processes. Basedupon design preferences, it is understood that the specific order orhierarchy of steps in the methods may be rearranged. The accompanyingmethod claims present elements of the various steps in a sample order,and are not meant to be limited to the specific order or hierarchypresented unless specifically recited therein. Additional elements,components, steps, and/or functions may also be added or not utilizedwithout departing from the disclosure.

While features of the disclosure may have been discussed relative tocertain implementations and figures, all implementations of thedisclosure can include one or more of the advantageous featuresdiscussed herein. In other words, while one or more implementations mayhave been discussed as having certain advantageous features, one or moreof such features may also be used in accordance with any of the variousimplementations discussed herein. In similar fashion, while exemplaryimplementations may have been discussed herein as device, system, ormethod implementations, it should be understood that such exemplaryimplementations can be implemented in various devices, systems, andmethods.

Also, it is noted that at least some implementations have been describedas a process that is depicted as a flowchart, a flow diagram, astructure diagram, or a block diagram. Although a flowchart may describethe operations as a sequential process, many of the operations can beperformed in parallel or concurrently. In addition, the order of theoperations may be re-arranged. A process is terminated when itsoperations are completed. In some aspects, a process may correspond to amethod, a function, a procedure, a subroutine, a subprogram, etc. When aprocess corresponds to a function, its termination corresponds to areturn of the function to the calling function or the main function. Oneor more of the various methods described herein may be partially orfully implemented by programming (e.g., instructions and/or data) thatmay be stored in a machine-readable, computer-readable, and/orprocessor-readable storage medium, and executed by one or moreprocessors, machines and/or devices.

Those of skill in the art would further appreciate that the variousillustrative logical blocks, modules, circuits, and algorithm stepsdescribed in connection with the implementations disclosed herein may beimplemented as hardware, software, firmware, middleware, microcode, orany combination thereof. To clearly illustrate this interchangeability,various illustrative components, blocks, modules, circuits, and stepshave been described above generally in terms of their functionality.Whether such functionality is implemented as hardware or softwaredepends upon the particular application and design constraints imposedon the overall system.

Within the disclosure, the word “exemplary” is used to mean “serving asan example, instance, or illustration.” Any implementation or aspectdescribed herein as “exemplary” is not necessarily to be construed aspreferred or advantageous over other aspects of the disclosure.Likewise, the term “aspects” does not require that all aspects of thedisclosure include the discussed feature, advantage or mode ofoperation. The term “coupled” is used herein to refer to the direct orindirect coupling between two objects. For example, if object Aphysically touches object B, and object B touches object C, then objectsA and C may still be considered coupled to one another—even if they donot directly physically touch each other. For instance, a first die maybe coupled to a second die in a package even though the first die isnever directly physically in contact with the second die. The terms“circuit” and “circuitry” are used broadly, and intended to include bothhardware implementations of electrical devices and conductors that, whenconnected and configured, enable the performance of the functionsdescribed in the disclosure, without limitation as to the type ofelectronic circuits, as well as software implementations of informationand instructions that, when executed by a processor, enable theperformance of the functions described in the disclosure.

As used herein, the term “determining” encompasses a wide variety ofactions. For example, “determining” may include calculating, computing,processing, deriving, investigating, looking up (e.g., looking up in atable, a database or another data structure), ascertaining, and thelike. Also, “determining” may include receiving (e.g., receivinginformation), accessing (e.g., accessing data in a memory), and thelike. Also, “determining” may include resolving, selecting, choosing,establishing, and the like. As used herein, the term “obtaining” mayinclude one or more actions including, but not limited to, receiving,generating, determining, or any combination thereof.

The previous description is provided to enable any person skilled in theart to practice the various aspects described herein. Variousmodifications to these aspects will be readily apparent to those skilledin the art, and the generic principles defined herein may be applied toother aspects. Thus, the claims are not intended to be limited to theaspects shown herein, but are to be accorded the full scope consistentwith the language of the claims, wherein reference to an element in thesingular is not intended to mean “one and only one” unless specificallyso stated, but rather “one or more.” Unless specifically statedotherwise, the term “some” refers to one or more. A phrase referring to“at least one of” a list of items refers to any combination of thoseitems, including single members. As an example, “at least one of: a, b,or c” is intended to cover: a; b; c; a and b; a and c; b and c; and a, band c. All structural and functional equivalents to the elements of thevarious aspects described throughout this disclosure that are known orlater come to be known to those of ordinary skill in the art areexpressly incorporated herein by reference and are intended to beencompassed by the claims. Moreover, nothing disclosed herein isintended to be dedicated to the public regardless of whether suchdisclosure is explicitly recited in the claims. No claim element is tobe construed under the provisions of 35 U.S.C. § 112, sixth paragraph,unless the element is expressly recited using the phrase “means for” or,in the case of a method claim, the element is recited using the phrase“step for.”

Accordingly, the various features associate with the examples describedherein and shown in the accompanying drawings can be implemented indifferent examples and implementations without departing from the scopeof the disclosure. Therefore, although certain specific constructionsand arrangements have been described and shown in the accompanyingdrawings, such implementations are merely illustrative and notrestrictive of the scope of the disclosure, since various otheradditions and modifications to, and deletions from, the describedimplementations will be apparent to one of ordinary skill in the art.Thus, the scope of the disclosure is only determined by the literallanguage, and legal equivalents, of the claims which follow.

What is claimed is:
 1. A method for a first network node, comprising:establishing, at a control plane network function implemented at thefirst network node, a security context for a client device; obtaining,at the control plane network function implemented at the first networknode, a user plane key for a user plane network function implemented ata second network node; and transferring, from the control plane networkfunction implemented at the first network node, the user plane key tothe user plane network function implemented at the second network node.2. The method of claim 1, wherein the establishing the security contextfor the client device includes performing a mutual authenticationprocedure with the client device.
 3. The method of claim 2, whereinobtaining the user plane key includes deriving the user plane key from asession credential established during the mutual authenticationprocedure.
 4. The method of claim 1, further comprising: obtaining, atthe control plane network function implemented at the first networknode, a control plane key for the control plane network function.
 5. Afirst network node, comprising: a communication circuit configured tocommunicate with one or more network entities; and a processing circuitcoupled to the communication circuit, the processing circuit configuredto: establish, at a control plane network function implemented at thefirst network node, a security context for a client device; obtain, atthe control plane network function implemented at the first networknode, a user plane key for a user plane network function implemented ata second network node; and transfer, from the control plane networkfunction implemented at the first network node, the user plane key tothe user plane network function implemented at the second network node.6. The first network node of claim 5, wherein the processing circuitconfigured to establish the security context for the client device isfurther configured to: perform a mutual authentication procedure withthe client device.
 7. The first network node of claim 6, wherein theprocessing circuit configured to obtain the user plane key is furtherconfigured to: derive the user plane key from a session credentialestablished during the mutual authentication procedure.
 8. The firstnetwork node of claim 5, wherein the processing circuit is furtherconfigured to: obtain, at the control plane network function of thenetwork node, a control plane key for the control plane networkfunction.
 9. A network node, comprising: a communication circuitconfigured to communicate with one or more network entities; and aprocessing circuit coupled to the communication circuit, the processingcircuit configured to: obtain, at a user plane network functionimplemented at the network node, a security context for a client device;determine, at the user plane network function implemented at the networknode, a key to be used at least for decryption or verification of a datapacket from the client device; receive, at the user plane networkfunction implemented at the network node, the data packet from theclient device; and decrypt and verify, at the user plane networkfunction of the network node, the data packet from the client devicebased on the key.
 10. The network node of claim 9, wherein theprocessing circuit configured to obtain the security context is furtherconfigured to: receive the security context from a control plane networkfunction implemented at the network node.
 11. The network node of claim9, wherein the processing circuit is further configured to: receive, atthe user plane network function implemented at the network node, a datapacket for the client device from an application server or gateway;determine, at the user plane network function implemented at the networknode, at least one key associated with the client device; and protect,at the user plane network function implemented at the network node, thedata packet for the client device using the at least one key.
 12. Thenetwork node of claim 11, wherein the processing circuit is furtherconfigured to: transmit, from the user plane network functionimplemented at the network node, the data packet for the client deviceto the next hop network node.
 13. The network node of claim 11, whereinthe processing circuit configured to protect the data packet for theclient device is further configured to: encrypt or integrity protect, orboth encrypt and integrity protect, the data packet for the clientdevice.